FullClass

Get revenue summary

get_revenue_summary

Read-onlyIdempotent

The studio's revenue between start_date and end_date, in minor units (cents) of the studio's currency, split into class bookings, gift cards sold and private event buyouts, with refunds, comps and chargebacks treated as the studio's own revenue report treats them. Bookings count on the day they were taken and gift cards on the day they were sold. With no dates it covers the 30 days ending today. Use it for any question about money; the note field explains how refunds were counted.

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

Input Schema

Name	Required	Description	Default
`end_date`	No	last 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
`start_date`	No	first 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

Name	Required	Description
`to`	Yes
`from`	Yes
`note`	Yes
`currency`	No
`timezone`	Yes
`total_cents`	Yes	the three totals above added together; the studio's revenue for the window
`class_bookings`	Yes
`private_events`	Yes
`gift_card_sales`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover the read-only, idempotent, non-destructive profile, and the description goes well beyond them: it discloses currency and minor-unit output, how refunds/comps/chargebacks are treated, the accrual basis (bookings on the day taken, gift cards on the day sold), the default 30-day fallback window, and that a note field records the refund treatment. That is exactly the behavioral context an agent needs to interpret and report the numbers correctly.

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-loads what is returned and in what unit, then the accrual rules, then the default window and the usage directive. Sentences each earn their place, though the parenthetical about refunds/comps/chargebacks plus the trailing note-field remark is slightly dense and could be tightened.

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?

An output schema exists so return-shape explanation is not required, and with only two optional parameters the description covers everything an agent needs: default window, unit and currency semantics, category split, and accounting treatment of refunds. Nothing material is left unstated for a tool of this complexity.

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 coverage is 100% and both parameters are already documented with inclusive-date and default-window behavior, so the schema carries the parameter burden. The description reinforces the no-dates default and adds the insight that dates are interpreted per the studio's timezone/currency, but adds no new syntax or format 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?

States a specific resource (studio revenue between two dates) plus the unit (minor units/cents of the studio's currency) and the breakdown (class bookings, gift cards sold, private event buyouts). The line 'Use it for any question about money' plus the booking/gift-card accrual rule plainly separates it from sibling tools like get_booking_summary or get_fill_rates that report counts, not money.

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 a clear usage directive ('any question about money') and states the default window when no dates are supplied, which is the main ambiguity for callers. It does not name an alternative tool or state when not to use it, so it stops short of explicit routing.

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

All FullClass 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?