Skip to main content
Glama

Statistics dashboard

stats_dashboard
Read-onlyIdempotent

Fetches figures and report lists for a chosen Booksy statistics section across a specified date range, with an option to bypass cached results.

Instructions

One statistics section with its figures and the list of reports inside it.

Input Schema

NameRequiredDescriptionDefault
freshNoSkip the local cache
dashboardYesSection
date_fromYesFirst day of the period (YYYY-MM-DD)
date_tillYesLast day of the period (YYYY-MM-DD)
time_spanNoPeriod typemonth

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior3/5

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds useful return context by saying it includes figures and a list of reports, but it does not explain caching behavior despite the fresh parameter or describe the response shape in detail.

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?

It is a single short sentence with no wasted filler. However, the structure is resource-first without a leading action verb, which slightly reduces immediate clarity.

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

Completeness3/5

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

Because there is no output schema, the description should clarify return values, and it does so only at a high level ('figures and the list of reports'). It does not clarify the relationship to report-oriented siblings or how dates and caching affect the result, though the schema and annotations cover the safety and parameter basics.

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 schema already documents all five parameters, including the dashboard enum and date formats. The description only loosely maps 'section' to the dashboard parameter and adds no meaningful parameter semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource as one statistics section and mentions the contents (figures and reports), but it lacks a clear action verb and does not distinguish this tool from similar statistics siblings such as stats_overview or stats_report_section.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus the many other statistics tools. The phrase 'One statistics section' only weakly implies usage, and no alternatives or exclusions are named.

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