Skip to main content
Glama

Get fill rates

get_fill_rates
Read-onlyIdempotent

How full classes were: seats booked as a share of capacity, for events starting between start_date and end_date, totalled and grouped by class (default), instructor, location or month. With no dates it covers the 30 days ending today; give future dates to see how the schedule is selling. Events with no capacity limit are counted apart, not mixed into the rate. Use it for fill over a period. For the specific upcoming classes that need seats sold, use list_underfilled_events; for whether booked guests actually came, use get_attendance_rates.

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_fill_rates"
  }
}

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_byNoclass, instructor, location, or month; defaults to class
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
bookedYes
eventsYesevents with a capacity set, the ones the fill rate is computed from
groupsYesfullest first
capacityYes
group_byYes
timezoneYes
truncatedNotrue when more groups existed than were returned
fill_percentYesoverall fill across the whole window
unlimited_bookedNo
unlimited_eventsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / group_by / description
      Previous value: -"class or month; defaults to class"New value: +"class, instructor, location, or month; defaults to class"
    • changedOutput schema / properties / groups / items / properties / group / description
      Previous value: -"the class name, or the month as YYYY-MM"New value: +"the class, instructor or location name, or the month as YYYY-MM; (no instructor) and (no location) collect 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 adds real behavioral context beyond them: the default 30-day window ending today, the meaning of future dates, and the important caveat that events with no capacity limit are "counted apart, not mixed into the rate". It does not cover pagination or ordering, but the presence of an output schema reduces the need.

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?

Content is front-loaded with the metric definition, then defaults, then the caveat, then routing to alternatives. The opening sentence is long and packs the grouping list in, but every sentence carries distinct information and there is no filler.

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 read-only aggregate metric tool with a full input schema and an output schema, the description covers metric definition, default window, grouping dimension, an edge case (unlimited-capacity events), and sibling routing. Nothing an agent needs in order to call it 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 would be 3; the description adds genuine meaning by explaining why an agent would pass future dates ("to see how the schedule is selling") and restating the grouping options and default. It stops short of adding format or constraint detail beyond the already thorough schema descriptions.

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 states a precise verb and metric ("seats booked as a share of capacity") plus the population and grouping ("events starting between start_date and end_date, totalled and grouped by class (default), instructor, location or month"). It explicitly names the sibling tools it is not (list_underfilled_events, get_attendance_rates), so an agent can separate it from alternatives without opening a 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?

It gives an affirmative use case ("Use it for fill over a period") and names two concrete alternatives with the conditions that select them: list_underfilled_events for "the specific upcoming classes that need seats sold" and get_attendance_rates for "whether booked guests actually came". Nothing about tool choice 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources