Skip to main content
Glama
davehenke

rekordbox-mcp

get_history_sessions

Retrieve DJ history sessions from rekordbox databases to analyze performance data and track metadata for review and organization.

Instructions

Get DJ history sessions from rekordbox.

Args: include_folders: Whether to include folder entries (years/months) limit: Maximum number of sessions to return

Returns: List of history sessions with metadata

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
include_foldersNo
limitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • MCP tool handler for get_history_sessions. The @mcp.tool() decorator registers this function as the tool implementation. It ensures database connection, fetches sessions from database helper, sorts them, applies limit, and returns serialized data.
    @mcp.tool()
    async def get_history_sessions(
        include_folders: bool = False,
        limit: int = 100
    ) -> List[Dict[str, Any]]:
        """
        Get DJ history sessions from rekordbox.
        
        Args:
            include_folders: Whether to include folder entries (years/months)
            limit: Maximum number of sessions to return
            
        Returns:
            List of history sessions with metadata
        """
        await ensure_database_connected()
        
        sessions = await db.get_history_sessions(include_folders=include_folders)
        # Sort by date created, most recent first
        sessions.sort(key=lambda x: x.date_created or "", reverse=True)
        return [session.model_dump() for session in sessions[:limit]]
  • Core database method that queries pyrekordbox database for history sessions, filters active ones, calculates track counts and durations, and constructs HistorySession models.
    async def get_history_sessions(self, include_folders: bool = False) -> List[HistorySession]:
        """
        Get all DJ history sessions from the database.
        
        Args:
            include_folders: Whether to include folder entries
            
        Returns:
            List of history sessions
        """
        if not self.db:
            raise RuntimeError("Database not connected")
        
        try:
            # Get all histories, filtering out soft-deleted ones
            all_histories = list(self.db.get_history())
            active_histories = [h for h in all_histories if getattr(h, 'rb_local_deleted', 0) == 0]
            
            sessions = []
            for history in active_histories:
                # Filter by type: Attribute 1 = folder, Attribute 0 = session
                is_folder = history.Attribute == 1
                
                if not include_folders and is_folder:
                    continue
                
                # Get track count for sessions
                track_count = 0
                duration_minutes = None
                if not is_folder:
                    try:
                        history_songs = list(self.db.get_history_songs(HistoryID=history.ID))
                        active_songs = [s for s in history_songs if getattr(s, 'rb_local_deleted', 0) == 0]
                        track_count = len(active_songs)
                        
                        # Calculate duration if we have tracks
                        if active_songs:
                            all_content = list(self.db.get_content())
                            content_lookup = {str(c.ID): c for c in all_content if getattr(c, 'rb_local_deleted', 0) == 0}
                            
                            total_seconds = 0
                            for song in active_songs:
                                content_id = str(song.ContentID)
                                if content_id in content_lookup:
                                    track_length = getattr(content_lookup[content_id], 'Length', 0) or 0
                                    total_seconds += track_length
                            duration_minutes = round(total_seconds / 60) if total_seconds > 0 else None
                    except Exception:
                        track_count = 0
                
                sessions.append(HistorySession(
                    id=str(history.ID),
                    name=history.Name or "",
                    parent_id=str(history.ParentID) if history.ParentID and history.ParentID != "root" else None,
                    is_folder=is_folder,
                    date_created=history.DateCreated,
                    track_count=track_count,
                    duration_minutes=duration_minutes
                ))
            
            return sessions
            
        except Exception as e:
            logger.error(f"Failed to get history sessions: {e}")
            return []
  • Pydantic BaseModel defining the output structure for HistorySession objects returned by the tool.
    class HistorySession(BaseModel):
        """
        Rekordbox DJ history session model.
        """
        
        id: str = Field(..., description="Unique history session identifier")
        name: str = Field(..., description="Session name (usually date)")
        parent_id: Optional[str] = Field(None, description="Parent folder ID")
        is_folder: bool = Field(False, description="Whether this is a folder")
        date_created: Optional[str] = Field(None, description="Date session was created")
        track_count: int = Field(0, ge=0, description="Number of tracks in session")
        duration_minutes: Optional[int] = Field(None, description="Total session duration in minutes")
        
        @field_validator('date_created', mode='before')
        @classmethod
        def validate_date(cls, v):
            """Convert datetime objects to strings."""
            if hasattr(v, 'strftime'):  # datetime object
                return v.strftime("%Y-%m-%d %H:%M:%S")
            return str(v) if v is not None else None
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions the return type ('List of history sessions with metadata') but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what 'history sessions' entail (e.g., time range, sorting). This leaves gaps for safe and effective use.

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?

The description is well-structured and front-loaded with the core purpose, followed by clear sections for args and returns. Every sentence adds value without redundancy, making it efficient and easy to parse.

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?

Given 2 parameters with 0% schema coverage and an output schema present, the description compensates well for parameters but lacks behavioral context. The output schema likely covers return values, so completeness is adequate but could be improved with more usage or behavioral details.

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 description coverage is 0%, so the description must compensate. It adds meaning for both parameters: 'include_folders: Whether to include folder entries (years/months)' and 'limit: Maximum number of sessions to return.' This clarifies their purposes beyond the schema's titles, though it could provide more context on default values or constraints.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Get DJ history sessions from rekordbox.' It specifies the resource (history sessions) and source (rekordbox), but doesn't explicitly differentiate from sibling tools like 'get_recent_sessions' or 'search_history_sessions', which would require more specific scope or method details.

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?

No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_recent_sessions' and 'search_history_sessions', the description lacks context on differences in scope, filtering, or use cases, leaving the agent to infer based on tool names alone.

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/davehenke/rekordbox-mcp'

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