get_artist

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'Get artist info by ID' without any details about the response format, possible errors, rate limits, or whether it requires authentication. Since it is a read operation, the lack of any behavioral context is a notable gap for an agent that needs to rely on this description alone.

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?

The description is a single, short sentence that is front-loaded with the action and key qualifier. There is zero waste, and it is appropriately concise for a simple getter tool.

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?

For a simple tool with one parameter and no output schema, the description is minimal but acceptable. However, it does not specify what 'artist info' includes (e.g., name, genres, popularity), so an agent might not know the full scope of the response. Given the lack of output schema and annotations, a bit more detail would improve completeness.

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% – the only parameter, 'id', is already described as 'Spotify artist ID'. The description's phrase 'by ID' does not add anything beyond the schema. Baseline is 3 because the schema already documents the parameter fully, and the description adds no extra meaning.

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 ('Get'), a clear resource ('artist info'), and a method ('by ID'). It is unambiguous and effectively distinguishes from sibling tools like get_artist_albums, which imply a different resource. Even without explicit sibling comparison, the purpose is crystal clear.

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?

No explicit guidance about when to use this tool versus alternatives, but the purpose is so straightforward that usage context is implied. An agent can infer that this tool is for fetching artist metadata when an ID is available. However, it does not mention any prerequisites or specific scenarios (e.g., when you need full artist details vs. albums).

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