Which integrations are available for this server?

Allows uploading and managing tracks on SoundCloud, including uploading MP3/WAV/FLAC files with metadata, updating track details, listing tracks, and deleting tracks.

How do I use SoundCloud MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SoundCloud MCP Upload track.mp3 with title 'My Song' and tags 'electronic'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

SoundCloud MCP

by David-J-Shibley

Overview Schema Source Related Servers Discussions Admin

Python

Remote

SoundCloud MCP

PyPI version License: MIT Python 3.10+ MCP

MCP server for uploading and managing tracks on SoundCloud using the official API.

Use it from Cursor or Claude Desktop to upload MP3s, update metadata, and manage your catalog — pairs naturally with suno-mcp for generate → upload workflows.

Features

Official SoundCloud API — OAuth 2.1 + PKCE, no browser scraping for uploads
Upload tracks — MP3, WAV, FLAC with title, description, tags, artwork
Manage library — list, get, update, delete tracks
Token refresh — automatic OAuth token renewal

Related MCP server: soundcloud-mcp-server

Requirements

Python 3.10+
SoundCloud Artist Pro account
A registered SoundCloud API app (soundcloud.com/you/apps)

Register your SoundCloud app

Field	What to enter
App name	`SoundCloud MCP` (or anything descriptive)
Description	`Personal MCP server for uploading AI-generated music to my SoundCloud account`
Website	`https://github.com/David-J-Shibley/soundcloud-mcp` (optional)
Redirect URI	`http://127.0.0.1:8765/callback` (must match exactly)

The Website field is optional — it is not used for OAuth. The Redirect URI must match character-for-character.

Quick Start

Install from PyPI

pip install soundcloud-mcp
cp .env.example .env
# Edit .env with client_id and client_secret from soundcloud.com/you/apps
soundcloud-mcp-auth

Install from source

git clone https://github.com/David-J-Shibley/soundcloud-mcp.git
cd soundcloud-mcp
python3 -m venv .venv
source .venv/bin/activate
pip install -e .
cp .env.example .env

Authenticate (one time)

soundcloud-mcp-auth

Tokens are saved to ~/.soundcloud-mcp/tokens.json.

If the browser page is blank/white, your redirect URI doesn't match — see Troubleshooting.

Cursor

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "soundcloud": {
      "command": "/absolute/path/to/soundcloud-mcp/.venv/bin/python",
      "args": ["-m", "soundcloud_mcp"],
      "cwd": "/absolute/path/to/soundcloud-mcp",
      "env": {
        "DYLD_LIBRARY_PATH": "/opt/homebrew/opt/expat/lib"
      }
    }
  }
}

Put credentials in .env in the project directory (recommended) — cwd lets the server load them automatically.

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "soundcloud": {
      "command": "/absolute/path/to/soundcloud-mcp/.venv/bin/python",
      "args": ["-m", "soundcloud_mcp"],
      "cwd": "/absolute/path/to/soundcloud-mcp"
    }
  }
}

Tools

Tool	Description
`soundcloud_get_me`	Your SoundCloud profile
`soundcloud_list_my_tracks`	List your uploaded tracks
`soundcloud_get_track`	Track details by ID
`soundcloud_upload_track`	Upload MP3/WAV/FLAC with metadata
`soundcloud_update_track`	Edit title, description, tags, artwork
`soundcloud_delete_track`	Remove a track

Example workflow (Suno → SoundCloud)

Generate a song with suno-mcp
Download the MP3 with suno_download_song
Upload with soundcloud-mcp:

Upload ~/Downloads/suno/my-song.mp3 to SoundCloud as "My New Track" with tags "electronic ai-generated"

Configuration

Variable	Default	Description
`SOUNDCLOUD_CLIENT_ID`	—	From soundcloud.com/you/apps
`SOUNDCLOUD_CLIENT_SECRET`	—	From soundcloud.com/you/apps
`SOUNDCLOUD_REDIRECT_URI`	`http://127.0.0.1:8765/callback`	Must match app settings
`SOUNDCLOUD_TOKEN_FILE`	`~/.soundcloud-mcp/tokens.json`	OAuth token storage

Troubleshooting

Blank/white OAuth page — Redirect URI mismatch. In soundcloud.com/you/apps, set exactly:

http://127.0.0.1:8765/callback

Use 127.0.0.1 not localhost, http:// not https://, no trailing slash.

Not authenticated — Run soundcloud-mcp-auth again.

Manual login — soundcloud-mcp-auth --no-browser prints the URL to paste into your browser.

Disclaimer

Unofficial project, not affiliated with SoundCloud. Use in accordance with SoundCloud's API Terms of Use.

Contributing

Issues and pull requests welcome on GitHub.

See PUBLISHING.md for PyPI release instructions.

License

MIT — see LICENSE.

Available Tools

7 tools

soundcloud_create_playlistB

Create a SoundCloud playlist (album/set) with ordered tracks and optional cover art.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It mentions mutation ('create') but lacks details on destructive effects, authentication, rate limits, idempotency, or error handling. This is insufficient for an agent to understand the full impact.

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 a single concise sentence, front-loaded with key information, and contains no extraneous text. It efficiently conveys the tool's purpose.

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 the presence of an output schema (not shown), return values need no explanation. However, the description lacks usage guidelines and behavioral transparency for a creation tool. It covers core functionality but misses contextual details needed for safe invocation.

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

Parameters3/5

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

The input schema already provides descriptions for all parameters (100% coverage), so the tool description adds minimal extra meaning. It reiterates 'ordered tracks' and 'optional cover art', which are already in the schema. Baseline 3 is appropriate.

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 clearly states the verb 'Create', the resource 'SoundCloud playlist', and includes key attributes like ordered tracks and optional cover art. It effectively distinguishes from sibling tools, none of which are for creating playlists.

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?

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Sibling tools are listed but not differentiated in terms of usage context.

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

soundcloud_delete_trackC

Delete a track from your SoundCloud account.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

The description only indicates a destructive action ('delete'), but lacks details on permanence, confirmation, side effects, or required permissions. No annotations are provided to compensate.

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 a single clear sentence with no filler. However, it could be more informative without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's destructive nature, the description is insufficient. It omits critical context like permanence, required ownership, and effects on associated data (e.g., playlists). No output schema is provided to describe return values.

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

Parameters1/5

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

With schema description coverage at 0%, the tool description adds no information about the 'track_id' parameter beyond what the schema provides. The description does not clarify how to obtain the ID or any constraints.

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 clearly states the action 'Delete' and the resource 'track' from SoundCloud account. It is specific and distinguishable from sibling tools like soundcloud_upload_track or soundcloud_update_track.

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, nor any conditions or prerequisites for deletion (e.g., ownership, permissions, effects on playlists).

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

soundcloud_get_meA

Get your authenticated SoundCloud profile.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/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 only states the basic action, missing details like authentication requirements, rate limits, or what the profile contains.

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 a single, concise sentence that immediately conveys the tool's purpose with no unnecessary words.

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 tool's simplicity (no parameters, output schema exists), the description is mostly complete. However, it lacks behavioral context that annotations would typically provide.

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?

With zero parameters and 100% schema coverage, the description does not need to add parameter info. Baseline 4 applies, and the description is adequate.

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 clearly states the action 'Get' and the resource 'your authenticated SoundCloud profile', distinguishing it from sibling tools that focus on tracks and playlists.

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?

Usage is implied by the resource type (profile vs. tracks/playlists), but no explicit when/when-not or alternative guidance is provided.

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

soundcloud_get_trackA

Get details for a specific track by ID.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description should cover behavioral aspects like auth requirements, error handling, and side effects. It only states the basic function, leaving gaps about what happens on invalid IDs or performance.

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 a single, front-loaded sentence with no wasted words. Every part is essential.

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 simplicity (1 param, good input schema, output schema exists), the description is mostly complete for retrieval. It could mention that the tool returns track details as defined by the output schema, but not having that does not significantly harm usability.

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

Parameters2/5

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

The schema parameter description already says 'SoundCloud track ID', and the tool description adds minimal value ('by ID'). With 0% schema description coverage, the tool description should compensate but does not provide additional meaning or format details.

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 clearly states the action (Get details), resource (specific track), and method (by ID). It distinguishes from sibling tools like soundcloud_create_playlist, soundcloud_delete_track, etc., which have different purposes.

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 description does not explicitly state when to use this tool over alternatives like soundcloud_list_my_tracks. It implies usage when a specific track ID is known, but no exclusions or guidance are provided.

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

soundcloud_list_my_tracksB

List tracks uploaded to your SoundCloud account.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. However, it fails to mention that this is a safe read operation, authentication needs, rate limits, or pagination behavior. Score 2 indicates insufficient transparency.

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

Conciseness3/5

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

The description is a single sentence, which is concise but lacks necessary detail. It could be expanded without becoming verbose. Score 3 indicates reasonable conciseness but not optimal.

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?

With one parameter and an output schema, the description is minimally adequate. However, it omits any mention of filtering, ordering, or pagination behavior. Score 3 reflects basic completeness with gaps.

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

Parameters1/5

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

The tool description contains zero parameter information (schema coverage 0%). The schema itself documents the 'limit' parameter, but the description adds no value beyond the schema. Score 1 reflects the lack of parameter semantics.

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 clearly states the action (list) and resource (tracks) with scope (uploaded to your account), distinguishing it from siblings like soundcloud_get_track (single) and soundcloud_upload_track (upload).

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 description does not explicitly state when to use this tool versus alternatives. While it implies use for listing own tracks, no guidance is given for not using it (e.g., for public tracks). Score 3 reflects implied usage without explicit context.

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

soundcloud_update_trackC

Update metadata for an existing track.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only states 'Update metadata', which implies mutation but lacks details on side effects, authentication requirements, rate limits, or idempotency. The minimal description does not adequately disclose behavior.

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

Conciseness3/5

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

The description is a single concise sentence. It is efficient but overly minimal for a mutation tool with many parameters. Every word earns its place, but the tool warrants more detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple optional parameters, mutation) and lack of annotations, the description is incomplete. It does not explain what fields can be updated, expected return values, or error conditions. An output schema exists but is not shown; the description itself is insufficient.

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

Parameters1/5

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

According to context, schema description coverage is 0%. The description adds no parameter meaning beyond what the schema provides. Many parameters (title, description, genre, etc.) have no descriptions in the schema either. The tool description fails to compensate for the low coverage.

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 verb (update) and resource (existing track), effectively distinguishing it from sibling tools like soundcloud_upload_track (which creates a new track) and soundcloud_delete_track. However, it could be more explicit about the scope of metadata updates.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not discuss prerequisites, when to use update instead of upload or delete, or any context about the update process.

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

soundcloud_upload_trackA

Upload an audio file to SoundCloud.

Requires OAuth login (run soundcloud-mcp-auth once). Uses your Artist Pro API credentials.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

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 discloses authentication requirements but lacks important behavioral details like file size limits, upload timeouts, success/failure responses, or potential side effects. The description is minimally transparent.

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 very concise with two sentences. It efficiently conveys the purpose and prerequisite without extraneous information. Front-loaded with the action.

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 the complexity of an upload tool and the presence of an output schema, the description covers the purpose and auth requirement but omits important constraints like supported audio formats beyond those listed, file size limits, and rate limits. It is moderately complete but has gaps.

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

Parameters3/5

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

The input schema already contains descriptions for all parameters (file_path, title, description, etc.), providing high coverage. The tool description adds only the auth prerequisite, which is not explicit in the schema. Therefore, it adds minimal additional meaning beyond the schema.

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 clearly states the verb (Upload) and resource (audio file to SoundCloud). It distinguishes from sibling tools like soundcloud_create_playlist, soundcloud_delete_track, etc., as the only upload tool.

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?

The description mentions a prerequisite (OAuth login and Artist Pro credentials) which guides when to use it. However, it does not explicitly state when to avoid using it or mention alternatives for updating tracks, though siblings exist.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv0.1.0Jun 18, 2026
- First observedsoundcloud_create_playlist
- First observedsoundcloud_delete_track
- First observedsoundcloud_get_me
- First observedsoundcloud_get_track
- First observedsoundcloud_list_my_tracks
- First observedsoundcloud_update_track
- First observedsoundcloud_upload_track

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-06-18 21:45 across 7 tools

Disambiguation5/5

Each tool targets a distinct resource and action (profile, track CRUD, playlist creation, track listing). There is no overlap or ambiguity between tool purposes.

Naming Consistency5/5

All tools follow the pattern 'soundcloud_verb_noun' with clear verbs (create, delete, get, list, update, upload). The pattern is uniform and predictable.

Tool Count5/5

Seven tools cover the essential operations for a SoundCloud integration without being excessive. Each tool has a distinct role, and the count is well-scoped for the domain.

Completeness3/5

Core track and profile operations are covered, but missing playlist management (update, delete, get) and other common features like search or streaming. Gaps are notable but not severe for basic usage.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Spotify
io.github.akutishevsky
Full Spotify Web API coverage - albums, artists, playlists, player controls, and more.
Entertainment & Media App Automation
2
DropTrack BOAuth
io.github.droptrack
Analyze tracks and manage customer music-promotion workflows through your DropTrack account.
Entertainment & Media Marketing
551
Audio Delivery Network A
net.audiodelivery
AI-manageable audio CDN: upload, transcode, normalize, stream & deliver audio, plus grounded docs.
Audio Processing Multimedia Processing
62
decksOAuth
com.powerpoint-sucks
Upload AI-written HTML presentations and manage expiring, revocable share links over OAuth.
Cloud Storage Content Management Systems
1

Related MCP Servers

SoundCloud MCP Server
Entertainment & Media Autonomous Agents API Testing
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
Provides Multi-Agent Conversation Protocol interface for the SoundCloud API, enabling AI agents to interact with SoundCloud's music streaming platform through natural language.
Updated a year ago (2025-07-16 14:28 UTC)
1
-
soundcloud-mcp-server
Entertainment & Media Search
marcellkehmstedt
A
license
Not graded
quality
D
maintenance
An MCP server that gives Claude access to your SoundCloud library, allowing you to manage playlists and tracks through natural language.
Updated 3 months ago (2026-06-18 16:58 UTC)
2
AGPL 3.0
SoundCloud MCP Server
Entertainment & Media Communication
jamiew
A
license
C
quality
B
maintenance
An MCP server that gives an assistant access to the SoundCloud API — search and discovery, your library, playlist management, social actions, and messaging.
Updated 4 days ago (2026-09-15 02:21 UTC)
32
MIT
YouTube MCP
Social Media Entertainment & Media
contactshahameer-stack
F
license
Not graded
quality
C
maintenance
Enables YouTube video upload, metadata updates, thumbnail management, stats retrieval, and analytics via the YouTube Data API v3 and Analytics API using OAuth 2.0.
Updated a month ago (2026-08-13 15:36 UTC)
-