Skip to main content
Glama
cotletdev

Booksy MCP Server

by cotletdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get report

get_report
Read-onlyIdempotent

Fetch Booksy Stats & Reports as JSON for a day, week, month or year. Get dashboard totals for appointments, revenue and clients, or pick a category and report key to pull full report tables.

Instructions

Numbers from Stats & Reports for a day, week, month or year, as JSON.

Returns one Stats & Reports category for a period: dashboard gives the totals for appointments, revenue and clients with the change against the previous period; any other category gives its highlight tables and the list of its reports. Pass report with a key from that list for the full report. Booksy counts one day, one Monday-to-Sunday week, one calendar month or one calendar year, so from and to must be such a period. Amounts come formatted in the business's currency. Booksy Biz Lite has the dashboard, revenue, appointments and clients; cash_flow, inventory, staff_members and marketing need Booksy Biz Pro.

Input Schema

NameRequiredDescriptionDefault
toYesLast day, inclusive: the same day, a Monday-to-Sunday week, a calendar month or year.
fromYesFirst day, inclusive.
reportNoReport key from `reports` of the category (e.g. appointments_summary) for its full tables.
categoryYesdashboard (totals), appointments, clients, revenue, cash_flow, staff_members, marketing, tips or inventory.
staff_idNoStaff member, only for the report performance_per_staffer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description layers on real behavioral context: the period-alignment rule for from/to, currency-formatted amounts, and a plan-tier gate. It stops short of saying what happens when a Lite business requests a Pro-only category (error vs. empty), which is the one behavioral edge an agent could still hit.

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 core purpose and return shape, then progressively narrower rules (category selection, report key, period alignment, plan availability). Dense but every sentence carries a distinct constraint; the plan-availability clause could be tightened slightly.

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 no output schema, the description carries the burden of describing returns and does so per category (dashboard totals plus delta vs. prior period; other categories expose highlight tables and a report list). Adequate for a 5-parameter read tool, with only the plan-restriction failure mode left unaddressed.

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 the baseline is 3, but the description adds meaning the schema does not: that `from`/`to` must land on a whole day/week/month/year boundary as Booksy counts it, and how `report` relates to the `reports` list returned by a category. `staff_id` scoping is left to 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 verb and resource ('Numbers from Stats & Reports ... as JSON') and immediately scopes it to a period and a single category. No sibling tool overlaps this territory, so an agent can route here without ambiguity.

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?

Explicitly explains when to use which category (dashboard for totals, other categories for highlight tables), when to add the `report` key (to get full tables), and when the tool is available at all (dashboard/revenue/appointments/clients on Lite; the rest need Pro). This is genuine routing guidance, not inference.

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

Deploy Server

Other Tools