soundcloud-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Every tool targets a distinct resource and action: search vs. get, tracks vs. playlists vs. users, and auth vs. content operations are clearly separated. Even similar tools like get_playlist, get_playlist_tracks, and get_playlist_reposters have unique, well-defined purposes.
Naming Consistency5/5
All tools follow the soundcloud_ prefix with consistent verb_noun naming: search_*, get_*, create_*, update_*, delete_*, set_*, and list_*. The small variation between get_ and list_ is meaningful, with get_ for single resources and list_ for collections, so the pattern is predictable.
Tool Count2/5
At 36 tools, the server exceeds the recommended range and becomes a heavy selection surface for an agent. While each tool is individually specific, the overall count is more than is typically appropriate and could be consolidated or trimmed.
Completeness5/5
The tool surface covers the full SoundCloud lifecycle: auth, search, track and playlist CRUD, engagement, user library exploration, and social actions. The api_request escape hatch also fills any edge-case gaps, making the set effectively complete for its domain.
Average 4.2/5 across 36 of 36 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, idempotent, and non-destructive. The description adds no additional behavioral context beyond the basic list operation, such as pagination behavior, ordering, authentication needs, or result shape. It does not contradict the annotations but contributes little beyond them.
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, and unambiguous sentence with zero filler. Every word contributes to communicating the action and resource.
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?
The tool is invokable because the schema documents the required parameters and annotations establish safety. However, the description lacks usage context such as pagination continuation, result ordering, or when to prefer this over listing a playlist's tracks, leaving the definition at a minimum-viable level.
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?
Schema description coverage is 100%: 'playlist' documents accepted formats and 'limit' documents range and default. The description adds no parameter-level meaning, so the baseline of 3 is appropriate because the schema already does the heavy lifting.
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 states a specific action ('List') and a precise target resource ('users who reposted a playlist'). This clearly differentiates it from sibling tools like soundcloud_get_playlist or soundcloud_get_playlist_tracks, with no ambiguity about the operation.
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?
There is no guidance about when to use this tool versus alternatives, no mention of prerequisites, and no reference to related tools such as soundcloud_set_repost or soundcloud_get_playlist_tracks. The agent must infer the intended use case entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false), non-idempotent behavior, and non-destructive behavior. The description adds only that it applies to the logged-in user and can use set_type for albums, which is more semantic than behavioral. It does not disclose side effects, default visibility, or duplicate handling.
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 sentence with no filler. It front-loads the core action and resource, then adds the set_type variant and the optional ordered tracks detail. Every part earns its place.
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?
The tool has 16 parameters, no output schema, and low schema description coverage, yet the description provides no return-value information, default behaviors, or guidance on the many optional metadata fields. It is sufficient for basic orientation but not for confident invocation without additional inference.
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?
Schema description coverage is only 31%, and the description compensates for just a couple of parameters (set_type and track_urns). Many metadata parameters such as genre, license, release, sharing, permalink, label_name, description, purchase_url, and purchase_title remain unexplained in both the schema and the description.
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 identifies the action (create), the resource (playlist or album), and the scope (logged-in user). It also mentions optional initial ordered tracks, which helps distinguish this from later modifications. However, it does not explicitly name sibling tools or contrast with update/add operations.
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 provides clear usage context: creating a new playlist/album for the logged-in user, with optional initial tracks. It implies this is for new resources rather than editing existing playlists, but it does not explicitly state when to prefer update_playlist or add_playlist_tracks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's 'List' phrasing adds no new safety behavior. The description provides no additional behavioral context such as pagination behavior, authentication requirements, or whether both kinds can be requested together.
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 filler. It communicates the core purpose efficiently and every word contributes meaning.
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 low parameter complexity, rich schema descriptions, and strong safety annotations, the description is largely sufficient for an agent to select and invoke the tool. The lack of an output schema is partly mitigated by the clear 'List the users' phrasing, though pagination behavior is not explicitly covered.
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 has 100% coverage with meaningful descriptions for all parameters, including the kind enum. The description itself adds no parameter semantics beyond what the schema already provides, so the baseline score of 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 states a specific action ('List') and a specific resource ('users who liked or reposted a track'). It clearly differentiates this tool from sibling tools like soundcloud_get_track_comments or soundcloud_get_track by focusing on engagement users rather than track metadata or comments.
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 does not state when to use this tool versus alternatives, nor does it provide exclusions or conditions. The only usage signal is implicit in the verb 'List' and the tool name, which is not enough to guide an agent through sibling tools like soundcloud_set_like or soundcloud_get_track_comments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a non-read-only, non-idempotent write operation. The description adds useful context by specifying 'as the logged-in user' and the optional timestamp anchoring, but it does not disclose side effects, response behavior, or failure conditions beyond what annotations and schema already imply.
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 well-structured sentence that front-loads the core action and immediately states the key optional behavior. There is no filler or redundant repetition of schema properties.
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?
For a simple 4-parameter write operation with no output schema, the description is largely complete: it identifies the actor, the target resource, the action, and the optional timestamp behavior. The main gap is that it does not hint at the return value or potential errors, but the schema covers the parameters thoroughly.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: 'optionally anchored at a position (timestamp_ms)' merely restates the timestamp parameter's meaning, and the track/body/account parameters are already fully described in 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 uses a specific verb and resource: 'Post a comment on a track' with the actor specified as 'the logged-in user'. It also mentions the optional timestamp anchor, making the tool's exact function clear and distinct from read-oriented siblings like soundcloud_get_track_comments.
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 implies the use case: use this when the logged-in user wants to comment on a track. It does not explicitly compare against alternatives or state when not to use it, so guidance is present but only implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, open-world, idempotent, and non-destructive behavior. The description adds useful context that results are based on SoundCloud's own recommendation logic ('more like this'), which helps the agent set expectations about the nature of the results.
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 sentence that conveys the core function and the conceptual framing ('recommendations / more like this') with no redundancy. It is front-loaded and easy to parse.
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?
For a simple read-only tool with a fully documented schema, the description provides enough context about what the tool returns and how it relates to the input track. The lack of an output schema is not a major gap given the straightforward list-return expectation.
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 schema already documents all three parameters with descriptions and defaults, so the description does not need to add parameter-level detail. It adds no extra parameter semantics beyond the schema, so the baseline of 3 applies.
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 identifies the resource (related tracks for a given track) and the purpose (recommendations / 'more like this'). It is specific enough to be distinct from a simple track lookup, though it does not explicitly contrast with sibling tools like soundcloud_get_track or soundcloud_search_tracks.
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: given a source track, retrieve SoundCloud's related/recommended tracks. However, there is no explicit guidance on when to choose this over search_tracks or get_track, nor any mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the 'public' qualifier, which suggests no special authentication is needed, but it does not discuss output shape, error behavior, or rate limits. There is no contradiction with the annotations.
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. It leads with the action and resource, then provides a useful field list without unnecessary padding.
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?
For a simple profile fetch with a fully documented schema and rich annotations, the description is nearly complete. It enumerates the returned profile fields, which is helpful since there is no output schema, though it does not specify error cases or exact response structure.
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?
Input schema coverage is 100%, so the schema already documents the user and raw parameters thoroughly. The description adds no parameter-specific semantics beyond what the schema provides, so the baseline score of 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 opens with the action 'Fetch' and clearly identifies the resource: a user's public profile. It enumerates the profile contents, which helps distinguish it from sibling tools like soundcloud_list_user_content, soundcloud_search_users, and soundcloud_me.
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 implies the tool is for retrieving a specific user's public profile, but it does not explicitly define when to use it versus alternatives. It does not mention when to prefer soundcloud_me, soundcloud_resolve, or soundcloud_list_user_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds pagination context and playlist-length guidance, but it does not explain page size, how to retrieve subsequent pages, or the shape of a page response.
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 two short sentences with no wasted words. The core purpose is front-loaded, and the alternative-routing note is placed immediately after.
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?
For a paginated tool with no output schema, the description is adequate but incomplete: it says tracks are listed page by page but never explains how pagination works, what a page contains, or how to use soundcloud_next_page. The parameter documentation and annotations cover most invocation needs, but return/pagination behavior is left for the agent to discover.
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 description itself adds no parameter-level meaning beyond the schema. Schema coverage is 67% because secret_token has no description, and the tool description does not compensate for that gap or clarify access/playlist semantics further.
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 states a specific verb and resource ('List the tracks of a playlist') and explicitly frames the pagination behavior. It also distinguishes itself from soundcloud_get_playlist by saying to prefer this tool for long playlists, so an agent can tell it apart from its sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete routing rule: prefer this over soundcloud_get_playlist for long playlists. This names the alternative and the condition that selects the tool, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond annotations: the results are ordered newest first, and each comment includes a track timestamp. This is meaningful extra context for an agent.
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 sentence with no filler. It front-loads the core action ('List comments on a track') before adding the ordering and timestamp details. Every phrase contributes useful information.
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?
For a simple read-only list tool with only one required parameter and full schema coverage, the description is quite complete. It covers ordering and a key output detail. The only small gap is that it does not mention pagination behavior or point to 'soundcloud_next_page', even though 'limit' exists in the schema.
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?
Schema description coverage is 100%; both 'track' and 'limit' already have clear descriptions in the schema, including type, constraints, and defaults. The tool description does not need to compensate. It adds no parameter-specific meaning beyond what the schema provides, so the 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 uses a specific verb and resource: 'List comments on a track'. It also adds distinguishing behavior by stating ordering ('newest first') and the key returned data (timestamp in the track). This makes it easy to tell apart from the write-oriented sibling 'soundcloud_comment_on_track'.
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 usage context is clearly implied: use this when you need to read comments for a track. However, the description does not explicitly state when to use it versus alternatives such as 'soundcloud_comment_on_track' or pagination via 'soundcloud_next_page', leaving some guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds a meaningful behavioral detail beyond annotations: 'Paginated via next_href.' It also clarifies the semantic meaning of each kind, which helps the agent understand what the call returns. It does not mention auth requirements or rate limits, but those are secondary for a read-only listing tool.
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 dense sentence but well-structured with a leading verb-object clause and semicolon-separated kind definitions. It is efficient and avoids filler, though the long enumeration is slightly harder to scan than a bulleted format would be.
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?
For a tool with no output schema, the description provides the essential operational context: the range of content kinds and pagination via next_href. Remaining parameters are well covered by the input schema's descriptions. It could be more complete by noting the response shape or that results are paginated arrays, but the given information is sufficient for correct invocation.
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?
With schema coverage at 83%, most parameters are already documented. The description adds essential meaning to the only under-documented parameter, kind, by enumerating and explaining all ten enum values, including subtle distinctions like followers vs followings and related_artists vs web_profiles. This goes beyond the bare enum in the schema and materially improves selection accuracy.
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 action ('List') and the resource ('content related to a user'), and the kind enumeration specifies exactly which content types are covered. It does not explicitly contrast with sibling tools like soundcloud_list_my_content, so it falls just short of full 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 description implies the tool is used when you need a user's tracks, playlists, likes, follows, or similar content, and explains how to choose the kind. However, it gives no explicit when-not-to-use guidance or pointers to alternatives (e.g., list_my_content for the current user, search_* for discovery).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds meaningful behavioral context by noting login is required and that the response includes upload quota and private counts. This is valuable beyond the structured annotations, especially since there is no output schema.
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 two short sentences with no filler. It front-loads the core resource ('Profile of the logged-in SoundCloud user'), adds specific content details, and ends with the necessary login caveat. Every sentence earns its place.
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?
For a simple read-only profile tool with zero required parameters and complete schema coverage, the description covers the essential context: target user, included data, and authentication prerequisite. With no output schema, slightly more detail about the full return shape could help, but the description is adequate for an agent to invoke it correctly.
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?
Schema description coverage is 100%, with both 'raw' and 'account' already documented in the input schema. The description does not add new parameter-level meaning beyond reinforcing that the profile belongs to the logged-in user. Baseline 3 is appropriate because the schema carries the parameter documentation burden.
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 title 'Get my profile' and tool name 'soundcloud_me' make the resource unambiguous, while the description clarifies it returns the logged-in user's profile, including upload quota and private counts. This clearly distinguishes it from a generic user-profile tool like soundcloud_get_user. The only minor weakness is that the description uses a noun phrase rather than an explicit verb, but the intent is unmistakable.
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 states the prerequisite 'Requires login' and establishes that this targets the logged-in user, giving implicit context for when to use it. However, it does not explicitly mention alternatives such as soundcloud_get_user for other profiles or explain when not to use this tool. Usage is implied rather than contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds a meaningful behavioral detail by noting the batch lookup mode when urns is supplied. It does not disclose pagination behavior or response shape, but for a non-destructive search tool the description offers reasonable added context beyond annotations.
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?
Two concise sentences with no filler. The main use case is front-loaded, and the batch-lookup special mode is added in a single additional clause. Every word contributes meaning.
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?
For a read-only search tool with no required parameters and full parameter schema coverage, the description provides enough context to invoke it correctly: search content is specified, the optional urns mode is explained, and limit semantics are in the schema. It could have mentioned pagination or how results relate to soundcloud_next_page, but the schema's 'Items per page' already hints at paging.
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?
Schema description coverage is 100%, so all three parameters (q, urns, limit) are already documented with meaningful descriptions. The description reinforces that 'urns' triggers batch lookup, which slightly augments the schema, but it does not need to carry the parameter-documentation burden. 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 action ('Search'), the resource ('SoundCloud users'), and the scope ('by name'), while also distinguishing it from sibling search tools like soundcloud_search_tracks and soundcloud_search_playlists by targeting the user/artist entity. The parenthetical 'artists, labels, listeners' further clarifies what kinds of users are in scope.
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 primary use case is clear: search users by name. The sentence 'Also does batch lookup when urns is given' explicitly describes when to use the batch lookup mode, which is useful guidance. However, it does not explicitly contrast with alternatives like soundcloud_get_user for known URNs, so it stops short of full when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide the write/idempotent/destructive profile, so the description only adds the context that the action is performed as the logged-in user and is controlled by the following boolean. It does not disclose rate limits, permissions, or side effects, but the simple semantics make those less critical.
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?
A single sentence with everything front-loaded: action, target, and boolean behavior. There is zero redundancy and no filler, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle action with two documented required parameters, the description plus schema and annotations are sufficient for correct invocation. It does not mention return values, but no output schema exists and the tool's success/failure outcome does not require further explanation for this action.
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?
Schema coverage is 100%, and all parameters are documented in the input schema. The description restates the following=true/false mapping that already exists in the schema without adding new meaning. The optional account parameter is also fully described in 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 uses a specific verb pair (follow/unfollow), names the resource (a user), and clarifies the actor (logged-in user). It clearly distinguishes this tool from sibling state-setting tools like set_like and set_repost by stating the exact action and its boolean control.
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 makes the tool's purpose immediately clear and implies the correct usage context for following or unfollowing a user. It does not explicitly name alternatives or state when not to use it, but no sibling tool performs the same action, so the implied usage is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a mutating, idempotent, non-destructive operation. The description adds value beyond those by disclosing partial-update semantics ('Only the provided fields change') and the ownership restriction ('owned by the logged-in user'). It does not contradict the annotations, and the added behavioral context is meaningful for correct invocation.
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 two short sentences with zero filler. It front-loads the action and resource, adds the HTTP method parenthetically, and places the important partial-update nuance in the second sentence. Every clause earns its place.
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?
For a tool with 21 parameters and no output schema, the description does a good job of stating scope, ownership, and patch semantics. The main gap is that it never mentions what the response will be (e.g., updated track object or empty body), which the agent would normally need to know. Annotations cover the safety profile, so this is a minor but real omission for a mutation tool without an output schema.
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?
Schema description coverage is only 43%, which is below the threshold where the schema alone can carry parameter documentation. The description does not compensate: it names no individual parameters, provides no formatting guidance, and does not clarify how the many undocumented optional fields (e.g., isrc, genre, label_name, purchase_url) should be supplied. The 'only provided fields change' note is useful globally but does not help with specific 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 states a specific verb ('Update'), a clear resource ('metadata of a track owned by the logged-in user'), and the exact endpoint (PUT /tracks/{urn}). The closing sentence 'Only the provided fields change' crisply distinguishes this from a full-replace update, and the operation is clearly distinguishable from sibling tools like upload_track, delete_track, and get_track.
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 provides clear context: this tool applies to tracks owned by the logged-in user, and it is a metadata-only update. It does not explicitly name sibling alternatives such as soundcloud_upload_track for creating tracks or soundcloud_set_track_storefront for storefront-specific updates, so it stops short of explicit when-to-use vs when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate non-read-only, non-idempotent, non-destructive behavior. The description adds meaningful behavioral details: file size and duration limits, supported formats, the PRO requirement for artwork, and a directive to confirm with the user. It does not mention side effects like duplicate tracks on repeated calls, but the provided context is strong.
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 four tightly packed sentences with no filler. The core action is front-loaded, followed by limits, formats, an important permission caveat, and a user-confirmation instruction. Every sentence adds operational value.
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?
For a 22-parameter tool with no output schema, the description covers key constraints and permission requirements but omits return behavior, error cases, and details about account selection or default values. It is adequate for making a basic call but not fully complete for an agent to anticipate all outcomes.
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?
Schema description coverage is only 50%, so the description needs to compensate, but it only adds meaning for a few parameters: file_path (local audio file), artwork_path (PRO only), and title/sharing/file (confirmation focus). Most of the remaining 22 parameters rely on schema descriptions, which leaves a moderate gap.
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 states a specific action 'Upload an audio file from the local filesystem as a new track', clearly identifying the verb, resource, and source. It also explicitly says 'new track', which distinguishes it from update_track, delete_track, and search-related siblings.
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 gives clear context for when to use the tool: uploading a local file as a new track for the logged-in user, with explicit limits and a user-confirmation requirement. It does not explicitly name alternatives or exclusion criteria, such as 'use update_track to modify an existing track', so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnly=false and destructive=false, so the mutation profile is covered. The description adds helpful context about the manual fallback scenario and acceptable input forms, but it does not disclose whether completing a login replaces an existing session or what happens on failure.
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?
Two sentences with no filler. The purpose and trigger condition are front-loaded, followed by the input format guidance. Every sentence earns its place.
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?
For a one-parameter auth completion tool, the description covers the trigger condition, the relationship to auth_login, and both acceptable input formats. It does not describe return values, but since no output schema exists and invocation does not depend on return values, this is a minor gap; a note about verifying success via auth_status could improve it further.
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 schema already describes the single parameter completely at 100% coverage, including the redirect URL and bare authorization code options. The description restates this in plainer terms but adds no meaningful new semantic information 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 states a specific action and resource: 'Finish a login started with soundcloud_auth_login'. It clearly distinguishes itself from the sibling auth tools by explaining that this is the manual fallback completion step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: when the browser callback could not reach the local listener. It names soundcloud_auth_login as the companion tool, giving the agent a clear decision rule and differentiating this from auth_status, auth_switch, and logout.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds value beyond that by disclosing irreversibility ('Permanently delete ... Irreversible'), which escalates the risk profile from merely destructive to no-undo, and by requiring explicit user confirmation. The ownership prerequisite is also disclosed. No contradiction with idempotentHint=true, since deleting an already-deleted track has no further effect.
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?
Two sentences with zero waste. The core action is front-loaded in sentence one, and sentence two delivers the critical confirmation requirement. Every clause ('permanently', 'owned by the logged-in user', 'irreversible', 'explicit confirmation') carries load-bearing information.
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?
Complete for a 2-parameter delete tool: the schema covers both parameters at 100%, annotations carry the safety profile (destructive, not read-only, idempotent), and the description supplies scope, permanence, and the confirmation gate. Minor gap: no statement about error behavior for tracks not owned by the user, but idempotentHint partially mitigates the repeated-deletion edge case.
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?
Schema description coverage is 100%: both track (URN, numeric id, or URL formats) and account (alias/username/URN, default-account fallback, pointer to soundcloud_auth_status) are fully documented in the schema. The description adds no parameter-level detail, but with full schema coverage the baseline of 3 applies — the schema does the heavy lifting.
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?
States a specific verb (delete), resource (track), and a meaningful scoping constraint ('owned by the logged-in user'). This goes beyond the title 'Delete track' and clearly separates it from siblings like soundcloud_update_track, soundcloud_set_track_storefront, and soundcloud_delete_playlist. The permanence qualifier adds precision.
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?
Provides clear context for invocation: this is the tool for permanently removing tracks the user owns, and the irreversibility warning adds an explicit usage condition — only after explicit user confirmation. It does not name alternatives or exclusions outright, but the sibling set (delete_playlist for playlists, update_track for mutations) makes the boundary obvious by naming convention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, and the description adds useful behavior beyond that: tracks are included by default and can be omitted, and secret_token is required for private playlists. It does not describe output shape, but the no-output-schema gap is modest for this getter.
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?
Two short sentences with the main behavior front-loaded and the special-case secret_token information placed second. There is no filler or repetition of schema details.
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?
For a read-only, mostly self-describing operation with five parameters, the description covers the essential behavior and the auth edge case. It is complete enough for an agent to call it correctly, though a pointer to the tracks-only sibling would make routing even more airtight.
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 coverage is 80% and the description adds meaning to the only undocumented parameter by saying secret_token is for private playlists. It also clarifies playlist can mean album or playlist, which aligns with the playlist 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?
Description states a specific verb ('Fetch'), a clear resource ('playlist / album'), and a distinctive scope ('with its metadata and by default its tracks'). This differentiates it from sibling soundcloud_get_playlist_tracks, which would return tracks without the playlist-level metadata.
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?
It gives one explicit condition: pass secret_token for private playlists. However, it does not explicitly mention alternatives such as soundcloud_get_playlist_tracks when only tracks are needed, or when to prefer search_playlists, leaving the when-to-use-vs-alternatives guidance mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by noting that secret_token unlocks private tracks and that the response is a metadata summary including access level. No contradiction with annotations.
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?
Two concise sentences, front-loaded with the core purpose and immediately followed by a high-value usage tip. No filler or redundant restating of the tool name.
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?
For a simple read-only metadata getter with full schema parameter coverage and safety annotations, the description is nearly complete. It lists representative return fields, mentions private-track handling, and relies on the schema for raw/secret_token specifics. No output schema exists, but the description gives enough context for correct 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?
Schema description coverage is 100%, so the schema fully documents track, raw, and secret_token. The description adds marginal value by explaining the purpose of secret_token in context, but it does not need to compensate for any schema gaps. 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 states a specific action ('Fetch') on a specific resource ('a track's metadata') and enumerates representative fields (title, artist, duration, counts, access level, permalink). This clearly distinguishes the tool from siblings like soundcloud_get_track_streams, soundcloud_get_track_comments, and soundcloud_get_track_engagement.
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 clearly frames when to use the tool: when you need track metadata. It also gives a specific usage condition: pass secret_token for private tracks. It does not explicitly name alternatives or exclusions, but the metadata focus plus the private-track instruction provide solid contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, which already indicate mutation (readOnlyHint=false) and non-destructiveness (destructiveHint=false), the description adds meaningful behavioral context: only the user's own playlists are affected and the order of remaining tracks is preserved. It does not detail edge cases like duplicate tracks or failures, but it covers the key operation semantics.
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 focused sentence with no filler. The main action is front-loaded, and the ownership constraint plus order-preservation detail follow immediately. Every element earns its place.
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?
For a moderately simple mutation tool with fully described parameters, no output schema, and annotations covering read-only/idempotent/destructive hints, the description is sufficiently complete. It gives the core semantics, the ownership requirement, and the order-preservation guarantee, which is enough for correct tool selection and 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?
Schema description coverage is 100%, so the input schema fully documents all three parameters including the optional account parameter. The description itself does not add parameter-level detail beyond restating the general removal intent, so it does not exceed the baseline.
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 a specific action ('Remove the given tracks'), a specific resource ('a playlist owned by the logged-in user'), and a behavioral guarantee ('keeping the order of the rest'). It is easy to distinguish from sibling tools like soundcloud_add_playlist_tracks, soundcloud_update_playlist, and soundcloud_delete_playlist.
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 provides clear context by restricting use to playlists owned by the logged-in user, which sets an important precondition. It does not explicitly name alternative tools or exclusion scenarios, but the action is specific enough that an agent can infer when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, so the description doesn't need to repeat that. It adds useful behavioral detail beyond annotations: the batch-lookup mode, paginated results, and the follow next_href contract. It does not discuss rate limits or result item shape, but the core behavior is 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?
Three concise sentences: the first states the primary purpose and filter options, the second covers the batch-lookup mode, and the third handles pagination. There is no filler or repetition of schema details.
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?
With 12 parameters, all fully described in the schema, and annotations covering the safety profile, the description covers the main behavioral contract: search, filters, batch lookup, and pagination. The only minor gap is that no output schema exists and the description does not specify the shape of each result item, but the tool name and search context make this acceptable.
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?
Schema coverage is 100%, so the schema already documents every parameter. The description adds a helpful high-level grouping of filters and explains the special meaning of urns, but it does not provide per-parameter semantics beyond the schema, so the 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 this is a full-text search for tracks with optional filters, distinguishing it from sibling search tools for playlists and users. It also notes the batch-lookup behavior when urns is provided, which separates it from single-track retrieval tools.
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 gives clear context for when to use the tool: searching tracks by text and filters, or doing a batch lookup via urns. It explicitly routes pagination follow-ups to soundcloud_next_page, but it does not explicitly contrast with soundcloud_search_playlists or soundcloud_search_users, though the track-specific wording makes the distinction fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotency and non-destructiveness, and the description adds useful behavioral context by stating the operation acts on the logged-in user's likes and that liked=false removes an existing like. This clarifies the state-changing effect beyond the raw schema.
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 compact sentence that front-loads the action and directly links the boolean values to their effects. There is no redundancy or filler; every word earns its place.
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?
For a straightforward state-changing tool, the description combined with the thorough input schema and annotations gives an agent enough to invoke it correctly: target kind, target format, liked value, and account selection are all covered. The lack of an output schema is not critical for a mutation call.
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 documents all parameters with 100% coverage, including the meaning of liked, target forms, bare-id kind requirement, and optional account selection. The description largely restates the liked=true/false semantics rather than adding new parameter meaning, so it stays at the baseline for fully covered schemas.
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 names a specific action ('Like' / 'remove the like'), the exact resources ('a track or playlist'), and the acting scope ('as the logged-in user'). This clearly distinguishes it from sibling social-action tools like soundcloud_set_repost and soundcloud_set_follow.
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 makes the usage context clear: it toggles like state for a track or playlist as a logged-in account. It does not explicitly state when not to use it, but no sibling tool provides the same like/unlike capability, so the lack of an explicit exclusion is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a mutating, non-destructive, idempotent operation. The description adds useful behavioral context by specifying that it acts as the logged-in user and that the boolean controls whether the repost is added or removed. This goes beyond the structured annotations without contradicting them.
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 information-dense sentence with no filler. It front-loads the core action and boolean semantics, and the title reinforces the toggling behavior without redundancy.
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?
For a four-parameter tool with complete schema coverage and no output schema, the description covers purpose, actor, and toggle behavior adequately. It does not explain edge cases like reposting an already-reposted item, but the idempotentHint annotation already signals that such calls are safe and idempotent.
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?
Schema description coverage is 100%, so the input schema already fully documents all four parameters. The description adds minor reinforcement about the reposted boolean and logged-in user scope, but no new parameter-level details such as examples, interaction between kind and target, or account resolution behavior.
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 identifies the action (repost or remove repost), the resource type (track or playlist), and the actor (logged-in user). It is immediately distinguishable from sibling tools like soundcloud_set_like, soundcloud_set_follow, and soundcloud_get_playlist_reposters.
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 makes the intended use evident: this is the tool for toggling a repost on a track or playlist. It does not explicitly name alternatives or exclusions, but there is no sibling tool that performs the same repost action, so the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutation, idempotency, and non-destructiveness. The description adds valuable behavioral context: the selection persists across sessions and affects subsequent tool calls, plus it returns the account list.
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?
Three short, purposeful sentences. The action is front-loaded, the behavioral consequence is explained, and the return value is noted with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, non-destructive account-switching tool, the description covers the purpose, the effect on other tools, persistence, and return value. Nothing essential is missing for correct 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 single parameter is fully documented in the schema with 'Alias, username or user URN of a logged-in account.' The description adds little beyond restating that it selects among logged-in accounts, so the schema carries the semantic weight.
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 states a specific verb and resource: 'Make one of the logged-in accounts the active (default) one.' It also clarifies the effect on other tools, distinguishing it from auth_status, auth_login, and auth_logout.
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 gives clear context for when the tool matters: after switching, tools that take no account parameter and public reads will use this account. It does not explicitly name alternative auth tools or exclusions, but the intended usage is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior, but the description adds meaningful context: the deletion is permanent, limited to the playlist owned by the user, and does not delete the tracks themselves. This adds value beyond the annotations and does not contradict them.
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?
Two tightly written sentences: the first states action, scope, and side-effect boundary; the second gives a crucial safety instruction. No filler or redundant repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema, the description covers permanence, ownership, non-deletion of tracks, and the need for confirmation. Combined with the schema and annotations, an agent has enough information to invoke it correctly.
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?
Schema description coverage is 100%, so both 'account' and 'playlist' are already well documented. The description adds no additional parameter-level meaning, which is acceptable because the schema carries the burden.
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 uses a specific verb ('delete') and resource ('playlist owned by the logged-in user'), and clarifies what it does NOT do ('tracks themselves are not deleted'). This clearly separates it from sibling tools like delete_track and remove_playlist_tracks.
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 states the ownership precondition ('owned by the logged-in user') and a strong safety guideline ('Get explicit confirmation first'). It implies when the tool is appropriate, though it does not explicitly name alternative tools for cases like removing tracks while keeping the playlist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds context about what the tool returns (kind, URN, summary) but does not disclose additional behavioral traits such as auth requirements, error behavior, or handling of invalid URLs. No contradiction with annotations.
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 two sentences with no filler. It front-loads the core transformation, lists the return values in a compact sequence, and ends with a terse, actionable usage directive. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter, read-only resolver with rich annotations, the description is sufficient. It explains the input URL scope, the output shape, and the intended workflow. The absence of an output schema is compensated by the explicit mention of kind, URN, and summary.
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 100%, so the baseline is 3. The description adds value by explicitly including on.soundcloud.com short URLs alongside soundcloud.com, and by explaining that the output URN is meant for use with other tools — which helps an agent understand the practical role of the url parameter beyond the schema's brief description.
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 states a specific action — turning a SoundCloud URL into its API resource — and clearly specifies what is returned: kind, URN, and summary. This clearly distinguishes it from the many get/search sibling tools, which operate on already-known resource identifiers rather than resolving arbitrary URLs.
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 explicitly says to 'Use this first whenever the user pastes a SoundCloud link,' which gives a clear and immediate usage context. It does not enumerate exclusions or alternatives, but for a resolver tool the primary workflow is obvious and no sibling tool competes for the same entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context by stating tracks are omitted by default 'to keep results small' and that 'show_tracks' changes this behavior. This exceeds what annotations alone convey without contradicting them.
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 two sentences with no filler. The core purpose is front-loaded, and the key behavioral caveat about tracks is included succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations and fully documented schema, the description covers the main behavioral nuance that would affect an agent's invocation: track omission and how to include tracks. No output schema exists, but the description adequately supports correct use for a search tool.
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?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the 'show_tracks' parameter's effect and rationale, adding meaning beyond the schema's default-value note, but it does not substantially explain other parameters because they are already well documented.
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 states a specific action and resource: 'Full-text search for playlists / albums.' It also distinguishes itself from sibling search tools by focusing on playlists/albums and mentioning that tracks are omitted by default, which clarifies its scope relative to track search.
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 clearly indicates when to use this tool: for full-text search of playlists or albums. It also instructs setting 'show_tracks' to include tracks, giving concrete usage guidance. It does not explicitly name alternatives like search_tracks or search_users, but the resource distinction is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations limited to coarse hints, the description supplies valuable behavioral detail: read-modify-write behavior, duplicate skipping, and the merge-back write. This materially goes beyond what readOnlyHint/destructiveHint convey and is not contradicted by annotations.
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?
Two tight sentences front-load the core action and add only one high-value behavioral detail after it. No filler or redundant restatement of the tool name.
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?
For a four-parameter mutation with no output schema, the description covers the core behavior, ownership constraint, and deduplication semantics. It omits edge-case behavior such as error handling or non-existent playlists, but the schema and description together are sufficient for correct 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?
Schema description coverage is 100%, so the schema already documents all four parameters and their meanings. The description adds minimal parameter-level detail beyond echoing the append/prepend behavior, which is the appropriate baseline.
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?
States a specific verb ('Append (or prepend)') and a specific resource ('tracks to a playlist owned by the logged-in user'), which distinguishes it from playlist metadata tools and track-removal siblings. It is immediately clear what action the tool performs.
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 gives clear context: use it to add tracks to a playlist the authenticated user owns, with optional prepend/append placement. It does not explicitly name alternatives such as update_playlist or remove_playlist_tracks, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnly=false and openWorldHint=true. The description adds useful behavioral context: it uses stored credentials, returns raw JSON, and paginate=true adds linked_partitioning for a compact page. It could warn more about arbitrary POST/PUT/DELETE side effects, but 'call any endpoint' plus openWorldHint substantially covers that.
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?
Three sentences with no filler: the escape-hatch intent is front-loaded, the usage rule is stated clearly, and the return/pagination behavior is summarized efficiently. Every sentence earns its place.
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?
For an open-ended raw API client, the description covers purpose, when to use it, return format, and pagination behavior. It does not explicitly describe auth/account switching or error handling, but those are documented in the schema and sibling auth tools, so the core guidance is complete for an expert escape-hatch tool.
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?
Schema description coverage is high (86%), so the parameter burden is mostly carried by the schema. The description adds little about individual parameters beyond what the schema already documents, such as the paginate behavior and stored credentials. This is adequate but not additive beyond the structured 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 uses a specific verb ('call') and a clear resource ('any https://api.soundcloud.com endpoint'), and labels itself an 'escape hatch' for cases no dedicated tool covers. This strongly distinguishes it from the extensive list of specialized SoundCloud sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: only when no dedicated tool covers the need, and points to the skill's api-reference for the dedicated alternatives. This gives the agent a clear routing rule and an exclusion condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful context beyond annotations by stating login is required and that results are paginated via next_href, which affects how an agent invokes and continues requests.
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 compact despite covering twelve kind variants, with a front-loaded purpose statement and a structured inline list. Every clause earns its place; there is no filler or redundancy.
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?
For a complex list tool with 6 parameters and 12 kind options but no output schema, the description covers the key operational facts: scope, login requirement, kind semantics, and pagination. A brief note about the response envelope would make it fully complete, but current coverage is strong.
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 coverage is 83%, so the schema already documents sort, limit, access, account, and show_tracks well. The description adds real value by mapping each kind enum value to its concrete meaning (e.g., 'followings_tracks (recent tracks from users I follow)'), which the schema does not provide.
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 uses a specific verb ('List') with a clear resource ('the logged-in user's library and social data') and enumerates exactly what each kind returns. The 'logged-in user' scope distinguishes it from siblings like soundcloud_list_user_content without requiring schema inspection.
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?
It clearly states this tool operates on the logged-in user's data and requires login, which tells an agent when this is the right choice versus user-scoped or search tools. It does not explicitly name alternatives or exclusions, but the context is strong enough to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds a concrete behavioral constraint beyond the annotations: only api.soundcloud.com URLs are accepted. It does not describe error handling for invalid URLs, but at this simplicity the added constraint is sufficient context.
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?
Two compact sentences with no filler. The core action and the critical domain constraint are both front-loaded and every word earns its place.
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?
For a single-parameter, read-only, idempotent helper with strong annotations, the description is adequate. It explains what is fetched, where the value comes from, and what kinds of URLs are allowed. Optional details like repeated pagination behavior or error response shapes are not essential here.
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 coverage is 100% and already defines next_href as 'the next_href value from a previous result'. The description reinforces this and adds the meaningful api.soundcloud.com URL restriction, giving the agent extra precision about acceptable parameter values.
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 uses a specific verb ('Fetch') and clearly identifies the resource ('next page of any paginated result') and the mechanism (next_href from a previous tool call). This distinguishes it from the resource-specific siblings and makes its generic role obvious.
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 clearly states when to use it: after a previous paginated result, passing the returned next_href. It also imposes a domain restriction (only api.soundcloud.com URLs are accepted). However, it does not explicitly mention alternatives like soundcloud_api_request or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail about what state the tool reports, including active account and in-progress logins, without contradicting the annotations.
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?
Two sentences with no filler: the first front-loads what the tool shows, and the second gives practical call timing. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only status tool, the description is complete: it states what info is returned, that it is the diagnostic first step, and when to invoke it. No output schema or further detail is needed for an agent to use it correctly.
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?
The tool has zero parameters and the input schema coverage is 100%, so there is nothing for the description to add about parameter meaning. This matches the baseline for a parameterless tool.
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 uses a specific verb ('Show') and names the exact resource: app credentials configuration, logged-in accounts (with alias, username, expiry), the active default account, and any login in progress. This clearly distinguishes the tool from auth action siblings like soundcloud_auth_login and soundcloud_auth_switch_account.
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 gives explicit conditions for when to call this tool: when a user-level action fails, before uploads/likes/playlist edits, or when the user talks about a specific account. However, it does not explicitly mention when not to use it or name alternative auth tools, so it stops short of a full when-to-use vs alternatives comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: URLs are signed and short-lived, only certain access levels yield streams, and stream requests count toward a 15,000 per 24h play limit. This is exactly the kind of operational detail an agent needs to handle these URLs correctly.
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?
Three dense sentences with no filler. The primary result is stated first, followed by lifecycle constraints and eligibility/rate-limit warnings. Every sentence earns its place and the most actionable information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple streaming-URL retrieval tool with no output schema, the description covers the result format, the signed/short-lived nature, access prerequisites, and the rate limit. The schema covers the single required parameter. Nothing essential is missing for an agent to select and invoke this tool correctly.
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 documents both parameters fully, including the accepted identifier forms for 'track' and the purpose of 'secret_token'. The description does not need to repeat parameter syntax, and the 100% schema coverage means the baseline of 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 states a specific verb ('Return'), a precise resource ('transcoded stream URLs of a track'), and enumerates the exact format variants (HLS AAC 160k, HLS MP3 128k, MP3 preview). This clearly distinguishes it from sibling tools like soundcloud_get_track, which would return metadata rather than playback streams.
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 gives clear usage context: fetch URLs right before playback because they are short-lived, and only tracks with playable/preview access have streams. It also notes the rate-limit implication. It does not explicitly name an alternative tool, but the context is strong enough for an agent to know when to call this tool versus a metadata or search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the endpoint, token deletion, default/active-account behavior, all=true semantics, and the fact that public reads keep working. These details go well beyond the sparse annotations and give the agent a clear model of the tool's side effects.
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 three tightly packed sentences with no filler. It front-loads the core action, then addresses parameter behavior, then adds the public-reads note. Every sentence earns its place.
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?
For a two-optional-parameter auth tool with no output schema, the description covers invocation semantics well: default account, all mode, and post-logout app-token behavior. It does not describe the response shape or error cases, but these are minor for this tool.
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 coverage is already 100%, so the baseline is 3. The description adds meaningful behavioral semantics beyond the schema by explaining what happens when account is omitted and what all=true does, which is valuable for correct invocation.
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 states a specific action ('Invalidate a stored user session (POST /sign-out)') and its consequence ('delete its tokens'), clearly identifying this as the logout tool. This distinguishes it from related auth siblings like login, status, and switch_account.
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 gives clear operational context: omitting account targets the active account, all=true removes every account, and public reads remain functional after logout. It does not explicitly name alternatives, but the usage behavior is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The most important behavior—whole-storefront replacement with clearing of omitted optional fields—is stated upfront, warning the agent to send all values that should remain. This adds meaningful behavioral nuance beyond the annotations' idempotent and read/write hints.
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?
Two compact sentences front-load the purpose and immediately warn about replacement semantics. No filler or repetition of schema details.
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?
For an 8-parameter mutation with no output schema, the description covers the core invocation context: target ownership, create-or-replace behavior, and the data-loss warning. It leaves response/error details to runtime feedback, but nothing essential for correct invocation is missing when combined with the schema.
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 coverage is high at 75%, so parameter details are largely already available. The description adds the crucial semantic that optional omitted parameters are cleared, which affects how every optional parameter should be considered when building arguments.
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 names a specific action ('Create or replace'), the target resource ('storefront (buy / link module)'), and its scope ('on a track owned by the logged-in user'). This is easily distinguishable from siblings like update_track or set_like.
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?
It is clear that the tool is for setting/replacing the buy/link module on the caller's own track and that every preserved field must be sent. It does not explicitly name alternative tools or state when not to use it, but the usage context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly=false, idempotent=true), the description discloses that the playlist must be owned by the logged-in user and that track_urns causes a full replacement of the existing track list. This is exactly the kind of side-effect context an agent needs before calling a mutating tool.
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?
Two sentences with no filler: the first states the core operation and scope, the second front-loads the replacement warning and routes incremental edits to the correct siblings. Every sentence earns its place.
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?
For a 17-parameter mutation with no output schema, the description covers the main risk (track-list replacement), the ownership constraint, and the appropriate alternatives. It does not explicitly state whether omitted metadata fields are preserved or what the response contains, so it stops just short of complete.
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?
With only 35% schema description coverage, the description adds some framing by calling the fields 'metadata' and emphasizing track_urns' replacement behavior. However, track_urns is already described in the schema as a 'Full ordered replacement track list', and most of the 17 parameters still lack semantic detail; ambiguous fields like 'release' are left to name-guessing.
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 names a specific verb ('Update'), a specific resource ('metadata of a playlist owned by the logged-in user'), and the optional replacement of the track list. This clearly separates it from sibling playlist-editing tools like soundcloud_add_playlist_tracks and soundcloud_remove_playlist_tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use this tool (metadata updates or full track-list replacement) and explicitly points to soundcloud_add_playlist_tracks / soundcloud_remove_playlist_tracks for incremental edits. This gives the agent a direct decision rule rather than leaving it to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses significant behavioral detail beyond annotations: the OAuth/PKCE flow, user browser interaction, account storage under an alias, active-account switching via make_default, local listener behavior, and the fallback path when the listener fails. The annotations are not contradicted; the description adds rich context about side effects and required follow-up.
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 compact yet information-dense, covering the flow, account storage, multi-account handling, callback mechanism, follow-up check, and failure fallback in three sentences. Every clause earns its place, and the primary purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-step OAuth login tool with no output schema, the description provides the essential return value (authorize_url), user-facing browser step, persistence behavior, listener behavior, post-login status check, and failure fallback. An agent has enough context to invoke the tool and know what comes next.
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?
Schema coverage is 100%, so the input schema already fully documents alias and make_default, including defaults. The description adds only minor context by referring to the alias default as the SoundCloud username and restating that make_default controls active-account status. This meets the baseline but does not substantially enrich parameter understanding.
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 a specific action ('Start the OAuth 2.1 (PKCE) login for a SoundCloud account') with a concrete resource and return value (an authorize_url). It distinguishes itself from sibling auth tools by explicitly referencing soundcloud_auth_status and soundcloud_auth_complete as follow-up/fallback steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: call to add accounts, call again for multiple accounts, and requires the user to be signed in as the other account in the browser. It also names alternatives/next steps (soundcloud_auth_status, soundcloud_auth_complete) and the condition for using the fallback, so an agent knows exactly how to proceed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![soundcloud-mcp MCP server](https://glama.ai/mcp/servers/auxa-m45/soundcloud-mcp/badges/card.svg)](https://glama.ai/mcp/servers/auxa-m45/soundcloud-mcp)

Score Badge

Copy to your README.md:

[![soundcloud-mcp MCP server](https://glama.ai/mcp/servers/auxa-m45/soundcloud-mcp/badges/score.svg)](https://glama.ai/mcp/servers/auxa-m45/soundcloud-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/auxa-m45/soundcloud-mcp'

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