Spotify Play Count MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your own Apify API token, used for tools/call and sent only in the Authorization header. Without a token, a call returns a clear error instead of running anything. | |
| APIFY_ACTORS | No | Optional comma-separated subset of the Actors to expose. | |
| APIFY_MCP_URL | No | Optional full endpoint override for the hosted Apify MCP endpoint. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| publicrecords--spotify-play-count-scraperA | Spotify Play Count & Monthly Listeners Scraper. Play counts for every track of any Spotify album, playlist or artist, plus monthly listeners and followers for artists. Optional streams per day for tracked tracks. No login. When to use: Use when you need Spotify play counts: the total plays of every track behind a track, album, artist or playlist link, plus an artist's monthly listeners, followers, world rank and top cities. Optional streams over the last 1, 7 and 30 days for tracks already in daily tracking; those fields stay empty for a track's first day and fill in once it has history. Good for release tracking, playlist checks and artist comparisons; not for private Spotify for Artists data or royalties. Returns: the run's dataset rows as structured JSON (one row per result), plus the run and dataset IDs for paging the full dataset. Behavior: starts one run of the Apify Actor "publicrecords/spotify-play-count-scraper" through Apify's hosted MCP gateway (mcp.apify.com) with your own APIFY_TOKEN; the run uses your Apify account. Read-only: it only reads public web data and changes nothing on the source site. Docs: https://apify.com/publicrecords/spotify-play-count-scraper |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
With only one tool exposed, there is no possibility of tool-to-tool confusion or misselection. An agent always knows exactly which tool to call for Spotify play-count data.
The name 'publicrecords--spotify-play-count-scraper' uses kebab-case with a vendor prefix and double hyphen, and describes an object rather than following a verb_noun pattern. There is no inconsistency to speak of with a single tool, but the convention is not the predictable action-oriented style an agent might expect.
A single tool is thin even for a narrow, single-purpose scraper wrapper, and it forces all queries (track, album, artist, playlist) through one monolithic entry point. The tool itself is substantial, but the surface is minimal rather than well-scoped across a few focused operations.
The tool covers the stated domain well: per-track play counts across tracks/albums/artists/playlists plus monthly listeners, followers, rank, cities, and optional stream history. Gaps exist around search/link resolution and historical export beyond the run's dataset paging, and private Spotify for Artists data is explicitly out of scope.