Skip to main content
Glama
Cifero74

mcp-apple-music

get_recently_played

Retrieve recently played albums, playlists, and stations from Apple Music to review your listening history and rediscover content.

Instructions

Get your recently played albums, playlists, and stations.

Note: Apple Music API returns recently-played containers (albums, playlists, stations) rather than individual tracks.

Args: limit: Number of items to return, 1–50 (default 10).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The implementation of the get_recently_played tool, which fetches recently played items from the Apple Music API using the authenticated client.
    async def get_recently_played(limit: int = 10) -> str:
        """Get your recently played albums, playlists, and stations.
    
        Note: Apple Music API returns recently-played containers (albums,
        playlists, stations) rather than individual tracks.
    
        Args:
            limit: Number of items to return, 1–50 (default 10).
        """
        client = _get_client()
        data = await client.get(
            "/me/recent/played",
            params={"limit": min(max(1, limit), 50)},
        )
        items = data.get("data", [])
    
        if not items:
            return "No recently played items found."
    
        lines = [f"🕐 Recently Played ({len(items)} items):\n"]
        for i, item in enumerate(items, 1):
            a = item.get("attributes", {})
            t = item.get("type", "")
            pid = item.get("id", "?")
            name = a.get("name", "?")
    
            if "album" in t:
                emoji = "💿"
                detail = f" — {a.get('artistName', '')}"
  • Registration of the get_recently_played function as an MCP tool using the @mcp.tool() decorator.
    @mcp.tool()
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It successfully discloses the key behavioral trait that the API returns containers rather than tracks. However, it omits the time window for 'recently', pagination behavior, and authentication requirements beyond the implied 'your'.

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?

The description is front-loaded with purpose, followed by the important behavioral Note, then parameter details. The structure is logical and appropriately sized for a single-parameter tool. The 'Args:' formatting is slightly informal but clear and wastes no space.

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?

Given the presence of an output schema, the description appropriately avoids duplicating return value structure. It covers the essential Apple Music-specific context (container behavior). Minor gap: the timeframe for 'recently' is undefined.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage (no 'description' field on the limit property). The description fully compensates by documenting the limit parameter with its semantic meaning ('Number of items to return'), constraints ('1–50'), and default value ('default 10') in the Args section.

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 opens with a specific verb ('Get') and resource ('recently played albums, playlists, and stations'). The Note explicitly distinguishes this from track-returning siblings like get_playlist_tracks or get_library_songs by clarifying it returns containers, satisfying sibling differentiation.

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

Usage Guidelines3/5

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

The Note about containers vs tracks provides implied usage guidance (don't use for individual tracks), but lacks explicit when-to-use recommendations or named alternatives. It does not explicitly contrast with get_library_* tools for history vs full-library access.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cifero74/mcp-apple-music'

If you have feedback or need assistance with the MCP directory API, please join our Discord server