soundcloud_profile

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add real context by saying the data is "Public data sourced from SoundCloud's own JSON API", which signals no auth needed and a first-party source, and it scopes to a single profile. However, it discloses nothing about failure behavior for invalid/deleted profile URLs, rate limits, or staleness of data.

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

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

Three tight sentences each earn their place: the top-loaded verb and object, then the useful field list, then a brief sourcing note. There is no filler or redundant restating of the name or schema.

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

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

Because there is no output schema, the description's explicit list of returned fields is valuable and partially compensates. That said, the description omits any notes on malformed URL inputs, missing profiles, or how to form the expected URL beyond "full" — a moderate gap for a tool with a single input parameter.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description reinforces that only a profile URL qualifies (as opposed to a track or playlist URL), but it adds no extra format requirements, examples, or validation detail beyond what the schema already provides.

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

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

The description states a specific verb and resource: "Get a SoundCloud user/artist profile", and it enumerates the concrete return fields (bio, avatar, counts, verified status). The scope of "one profile" clearly distinguishes this from sibling tools like soundcloud_track, soundcloud_playlist, soundcloud_user_tracks, and soundcloud_search without needing to open their schemas.

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

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

The description implies usage: when you already have a full profile URL and want profile-level stats, you call this. However, it does not explicitly state when not to use it, nor does it name alternatives such as soundcloud_search for finding profiles without a URL, or soundcloud_user_tracks for seeing a user's tracks.

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