Skip to main content
Glama

Get booking summary

get_booking_summary
Read-onlyIdempotent

Booking activity for bookings made between start_date and end_date (the day the booking was taken, not the day the class runs): confirmed bookings, seats, cancellations with a cancellation rate, and failed payments, grouped by day, month (default), class, instructor, location or price_option. With no dates it covers the 30 days ending today. Its booked_value_cents is not revenue, as it does not net off refunds or include gift cards and buyouts; for any money question, use get_revenue_summary.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_booking_summary"
  }
}

Input Schema

NameRequiredDescriptionDefault
end_dateNolast day to include, inclusive, YYYY-MM-DD; when left out it is today, or the 30th day from start_date when only start_date is given
group_byNoday, month, class, instructor, location, or price_option; defaults to month
start_dateNofirst day to include, YYYY-MM-DD in the studio's timezone; when left out the window is the 30 days ending on end_date

Output Schema

NameRequiredDescriptionDefault
toYes
fromYes
noteYes
seatsYesseats across those confirmed bookings
groupsYes
bookingsYesconfirmed bookings created in the window
canceledYesbookings created in the window that are now canceled
currencyYes
group_byYes
timezoneYes
truncatedNo
payment_failedYesbookings whose payment failed
booked_value_centsYessum of the totals of the confirmed bookings, in cents
cancellation_rate_percentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / group_by / description
      Previous value: -"day, month, class, or price_option; defaults to month"New value: +"day, month, class, instructor, location, or price_option; defaults to month"
    • changedOutput schema / properties / groups / items / properties / group / description
      Previous value: -"the day, the month as YYYY-MM, the class name, or the price option name"New value: +"the day, the month as YYYY-MM, or the class, instructor, location or price option name; (no instructor) and (no location) collect bookings for events without one"
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description still adds real context beyond them: the default 30-day window ending today, the default grouping of month, and the caveat that booked_value_cents is not revenue. It stops short of describing response shape or pagination, though an output schema exists to cover that.

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?

The core purpose and the revenue caveat are front-loaded, and the sentences carry dense, useful information. There is minor repetition of schema content (the group_by option list and defaults), which slightly dilutes an otherwise tight definition.

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?

With an output schema present, the description doesn't need to enumerate return fields, and it correctly spends its words on the two things structure can't convey: date-window defaults and the booked_value_cents-vs-revenue distinction. Nothing an agent needs to select or invoke this tool correctly is missing.

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 baseline is 3, but the description adds meaning the schema doesn't: it clarifies that the date range refers to when the booking was taken rather than when the class runs, and that grouping defaults to month. The group_by value list is repeated from the schema, which is the only redundant part.

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 names a specific resource (booking activity), the exact metrics returned (confirmed bookings, seats, cancellations with rate, failed payments), and the grouping dimensions. It also disambiguates the date semantics ('the day the booking was taken, not the day the class runs'), which no sibling name alone would convey.

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 states explicitly when not to use it and names the alternative: 'for any money question, use get_revenue_summary,' with the reason (booked_value_cents doesn't net refunds or include gift cards/buyouts). The default window when no dates are given is also stated, so an agent knows the fallback behavior without guessing.

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