Listening Companion
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SOUNDCLOUD_SCOPE | No | Optional scope for SoundCloud API | |
| SOUNDCLOUD_CLIENT_ID | No | SoundCloud API client ID | |
| SOUNDCLOUD_CLIENT_SECRET | No | SoundCloud API client secret | |
| LISTENING_COMPANION_REDIRECT_URI | No | Redirect URI registered with SoundCloud |
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 | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| connection_statusA | Return local connection state without provider metadata or tokens. |
| connect_accountA | Create a short-lived local browser authorization receipt; never returns a token. |
| disconnect_accountA | Clear local tokens and all in-memory provider/result/cursor state. |
| get_profileB | Fetch the authenticated profile into an expiring local viewer receipt. |
| recent_playsA | Fetch only the current API's last-25 recently played tracks. |
| liked_tracksA | Fetch liked tracks into an expiring local viewer receipt. |
| liked_playlistsC | Fetch liked playlists into an expiring local viewer receipt. |
| my_playlistsC | Fetch the user's playlists into an expiring local viewer receipt. |
| followingsC | Fetch followed users into an expiring local viewer receipt. |
| following_tracksA | Fetch followed-user tracks with limit and offset; this endpoint does not use linked_partitioning. |
| search_tracksA | Search public tracks; live metadata stays in the local viewer. |
| search_playlistsA | Search public playlists; live metadata stays in the local viewer. |
| search_usersB | Search public users; live metadata stays in the local viewer. |
| resolve_resourceA | Resolve an HTTPS SoundCloud permalink through an allowlisted API redirect. |
| get_trackA | Fetch a track by numeric ID or canonical soundcloud:tracks:... reference. |
| get_playlistB | Fetch a playlist by numeric ID or canonical soundcloud:playlists:... reference. |
| playlist_tracksB | Fetch playlist tracks with bounded pagination. |
| related_tracksC | Fetch related tracks using /tracks/{soundcloud:tracks:...}/related. |
| classify_podcastsB | Classify a prior local result, or classify explicitly synthetic fixture items. |
| recommendB | Combine local history/likes/following/search signals into new deterministic recommendations. |
| get_preferencesA | Read the explicitly saved minimal preference_profile only. |
| save_preferencesA | Save a minimal preference_profile only after explicit consent=true. |
| delete_preferencesA | Delete the saved preference_profile. |
| demo_catalogA | Return synthetic fixture metadata for local testing; it never contacts SoundCloud. |
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 24 tools
Each tool maps to a distinct action or resource: auth, profile, play history, liked items, playlists, followings, search, track/playlist lookup, recommendations, preferences, and demo fixtures. Even similarly named tools like liked_tracks and following_tracks are clearly separated by their descriptions.
The set mixes consistent verb_noun names like get_track and search_tracks with bare noun endpoints like recent_plays, liked_playlists, and demo_catalog. All names are readable snake_case, but the lack of a uniform verb prefix for fetch/list operations makes the pattern inconsistent.
With 24 tools, the server sits in the heavy 16-25 range. Each tool has a specific purpose, but many are thin read-only retrievals that could be consolidated, so the count feels slightly excessive for the core companion scope.
The surface covers auth, profile data, listening history, likes, playlists, followings, search, track/playlist retrieval, recommendations, podcast classification, and preference CRUD. Minor gaps exist, such as no direct user-lookup or user-track endpoint, but agents can complete the main listening-companion workflows.