Skip to main content
Glama
rcnsh

music-warehouse-mcp

by rcnsh

Plays per day, week or month

daily_play_counts
Read-onlyIdempotent

Count plays per local day between two dates, filling quiet days with 0; group results by week or month for longer spans.

Instructions

How many plays on each local day between two dates, quiet days as 0, optionally summed into weeks (from Monday) or months. Use month or week for spans longer than a few months.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoLast day, YYYY-MM-DD; default today
fromNoFirst day, YYYY-MM-DD; default 29 days ago
group_byNoDefault day

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed world), so the bar for extra disclosure is lower, and the description clears it: it discloses that days are "local" (timezone semantics), that empty days are returned as 0 rather than omitted, and that weeks start Monday. These are real behavioral traits not derivable from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core behavior, then the rollup option and its selection rule. No filler and no repetition of schema content.

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?

For a three-parameter read-only tool with no output schema, the description conveys the essential shape of the result (a per-day series with zeros) and the rollup behavior. It stops just short of describing response structure or format, but nothing needed 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 the baseline is 3, but the description adds meaning the schema lacks: week buckets begin Monday, day bucketing is on the local calendar day, and week/month exist specifically for long spans. Defaults and formats are already in the schema and are not restated.

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 aggregation: daily play counts between two dates, with silent days materialized as 0 and optional week/month rollups. That level of specificity clearly separates it from raw-play siblings (get_plays) and ranking siblings (top_tracks, top_artists), so an agent can select it without opening the schema.

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?

"Use month or week for spans longer than a few months" is concrete, condition-based guidance on granularity choice. It does not name alternative tools or state when this tool should be avoided, so it falls short of the explicit alternatives/exclusions a 5 requires.

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