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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context that this is a connection/auth probe and enumerates the returned fields, but says nothing about failure behavior (e.g. what an unauthenticated result looks like) or rate limits.

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?

A single short sentence that front-loads the tool's function and appends the returned fields. No filler, no redundancy.

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?

With an output schema present and zero parameters, the description needn't explain return values or arguments; it still names the key fields. The only gap is the absence of guidance on when this probe should be invoked relative to the other tools.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The field list in the description concerns outputs, not inputs, and the output schema already covers those.

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?

States a specific verb+resource in 'Проверка подключения' (connection check) and names the returned fields: login, name, Plus subscription status. This clearly separates it from the music-content siblings (search, get_liked_tracks, etc.), though it doesn't explicitly name an alternative.

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?

Usage is only implied: the phrase 'Проверка подключения' suggests it is the way to verify authentication/connectivity, but the description never states when to call it versus other tools or what precondition it validates. No exclusions or alternatives are given.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the write/safety profile is covered. The description adds almost nothing behavioral beyond that — no mention of permissions, duplicate handling, or what the required 'kind' parameter controls. It corroborates rather than extends 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.

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

Two short, front-loaded sentences with no filler; the purpose leads and the id format follows. It is appropriately sized for such a small tool, though it is arguably too terse given the undocumented required parameter.

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?

An output schema exists, so return values need not be described. However, a required parameter ('kind') with no meaning anywhere, no usage guidance, and no behavioral context beyond the annotations leave the definition under-specified for correct invocation.

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 0%, so the description carries the full burden of explaining three parameters. It documents only track_ids, giving the id format ('123:456' or '123'), while the required 'kind' integer and the 'at_start' boolean remain completely unexplained in both schema and description.

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 in Russian ('Добавляет треки в мой плейлист' — adds tracks to my playlist), which clearly distinguishes it from remove_tracks_from_playlist. It scopes to 'my' playlists, but does not explicitly name alternatives or state the boundary against like_tracks or create_playlist.

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 when-to-use guidance, prerequisites, or alternatives are given. The only implied usage is 'my playlist', and nothing tells the agent when to prefer this over remove_tracks_from_playlist, like_tracks, or create_playlist. The agent must infer context entirely.

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

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

Annotations already declare this is a non-read, non-destructive, open-world write, so the safety profile is covered. The description notes the default visibility is private, but this merely repeats the schema default rather than adding new behavioral context (no auth, side-effect, or idempotency detail).

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?

Two short sentences, front-loaded with the action and default behavior, with no wasted words. The mention of the return value is redundant given the output schema but very brief.

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?

An output schema exists, so return details need not be described, and annotations cover the safety profile. However, the undocumented required title parameter and lack of any usage or permission context leave a modest gap for a mutation tool.

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 0%, so the description must carry parameter meaning, but it only alludes to the visibility default ('по умолчанию приватный') and says nothing about the required 'title' parameter. It fails to compensate for the documentation gap.

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?

States a specific verb+resource ('Создаёт новый плейлист'), which clearly distinguishes it from read-side siblings like list_my_playlists and get_playlist_tracks. It does not explicitly name or contrast with any alternative, but the create action is unambiguous.

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?

There is no when-to-use, when-not-to-use, or alternative guidance. The intent (make a new playlist) is only implied by the verb, and nothing routes the agent versus siblings like add_tracks_to_playlist.

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

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

Annotations already declare destructiveHint=true, but the description adds important context beyond that: the operation is 'НЕОБРАТИМО' (irreversible) and requires explicit user confirmation. These two facts are not encoded in the annotations and materially improve safe invocation.

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?

Two sentences, front-loaded with the irreversible nature and the user-confirmation requirement. Every clause adds distinct operational value.

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?

Output schema exists so return values need not be explained. However, with both parameters required and 0% schema coverage, the description should clarify 'kind' and the exact matching semantics of 'confirm_title'. The safety guidance is complete but parameter guidance is not.

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 0% and the description only explains 'confirm_title' as a protection mechanism. The 'kind' parameter is left unexplained, forcing the agent to infer its meaning. The description partially compensates but leaves a required parameter opaque.

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?

States a specific verb ('удаляет') and resource ('мой плейлист целиком') with irreversible scope ('НЕОБРАТИМО'). No sibling is similarly named, so the destructive 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.

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

Explicitly requires asking the user before invocation, which is clear precondition guidance. Does not reference alternative tools like create_playlist or list_my_playlists, but for a destructive operation the primary guidance is sufficient.

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

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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description goes well beyond them: it discloses that two files are produced, their exact formats and fields, the destination folder, the YANDEX_MUSIC_EXPORT_DIR override, and the source/kind dependency.

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 compact sentences, front-loaded with the core action and scope, followed by format/prerequisite detail. Dense but every clause carries information; only the parenthetical field list is slightly granular.

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?

With an output schema present, return values need no explanation, and the side effect (files written to a known location) is fully covered. The remaining gap is the undocumented file_name and owner_uid, which an agent would have to guess at.

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 coverage is 0%, so the description must carry all four parameters. It meaningfully explains source (likes/playlist) and kind (required for playlist), but file_name and owner_uid are never mentioned, leaving half the parameters undocumented anywhere.

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?

States a specific verb (export/write to file), the exact resource (ALL tracks — likes or a playlist), and the output form (.txt and .csv), explicitly noting it does NOT push them into chat. That phrase alone separates it from siblings like get_liked_tracks and get_playlist_tracks, which do load results into chat.

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?

Clear context for use — when you want files on disk rather than chat output — and it states a concrete prerequisite: kind is required when source="playlist". No exclusions or named alternative tools are given, so it stops short of the explicit when-not guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing behavioral on top of that — no note on whether album info and tracklist are always both returned, no pagination or availability caveats.

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?

A single short, front-loaded sentence with no filler or repetition. It is efficient, though its brevity reflects under-specification rather than disciplined editing.

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?

An output schema exists, so return values need no explanation, and the tool is low-complexity with one parameter. Even so, the description supplies no usage context, no parameter meaning, and is in a different language from the sibling tool names, leaving real gaps.

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?

The single album_id parameter has 0% schema description coverage, and the description never explains it — only the word 'альбом' hints that an album identifier is expected. No format, no note that it is required.

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 phrase 'Информация об альбоме и его треклист' names the resource (album + its tracklist), which loosely distinguishes it from get_playlist_tracks and get_artist_tracks, but it is a bare noun phrase with no verb and no scope details, so the purpose is only implied rather than stated.

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?

There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool. The agent is left to infer that this is the album-scoped counterpart of get_playlist_tracks/get_artist_tracks entirely on its own.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description contributes nothing beyond that: no ordering rule, no limit behavior, no mention of what 'popular' means or whether results are scoped to the user's region/library.

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?

One short sentence is front-loaded and technically waste-free, but the sizing is under-specification rather than conciseness: too little content for a tool with two parameters and a popularity-ordering concept that needs explanation.

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?

An output schema exists, so return values need not be described, and annotations cover safety. But with zero parameter documentation, no usage routing, and an unexplained 'popular' notion, the definition is not complete enough for an agent to call it confidently versus its many siblings.

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 0% across two parameters, so the description must carry the burden and does not. 'Popular tracks' only faintly implies a popularity ordering that relates to the undocumented limit parameter, and artist_id is never explained as a required integer identifier.

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 what the tool returns — the popular tracks of an artist — which is a clear resource with an implicit retrieval verb, so it is not a tautology. However, it names no sibling and gives no scope boundaries, so an agent cannot distinguish it from get_album_tracks, get_similar_tracks, or get_chart without opening the schema.

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?

There is no when-to-use, when-not-to-use, or alternative tool guidance at all. With 15 sibling tools including several other track-listing tools, the absence of routing guidance is a real gap.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and network reach are covered. The description adds nothing beyond that — no indication of chart region/scope, freshness, or what the chart represents, which is the kind of context that would justify credit here.

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?

It is a single front-loaded fragment with zero waste, but it is under-specified rather than concise: the entire description is four words and carries no operational information.

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?

An output schema exists, so return values need not be explained, but the undocumented limit parameter and the total absence of usage context leave the definition materially incomplete for a tool with one sibling-overlapping competitor.

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 0%, and the single 'limit' parameter (default 50) is undocumented in both the schema and the description. The description does not compensate at all, so the agent must guess what limit bounds — number of chart entries versus something else.

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 phrase names a specific resource ('current Yandex Music chart'), so an agent knows this returns chart data rather than playlists or tracks. However it is a bare noun phrase with no verb and no differentiation from siblings like get_my_wave or get_listening_history, which also return ranked/streamed music data.

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?

There is no usage guidance at all: nothing says when to call this instead of get_my_wave, search, or get_listening_history, and no prerequisites or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior beyond the annotations: the newest-to-oldest ordering and a practical cap of 500 on limit, which is useful operational context 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.

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

Two short sentences with zero filler; the resource plus ordering come first and the limit advice follows. Every clause earns its place.

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 two-parameter read-only listing tool with an output schema (so return values need no explanation) and solid annotations, the description supplies ordering and the limit cap. The only real gap is the undocumented offset 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 0%, so the description must carry the parameter burden, and it only partially does. It clarifies limit (value 'up to 500' for analysis) but says nothing about offset, leaving half the parameters undocumented anywhere.

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?

States a specific verb+resource: it returns tracks from the 'Liked' (Мне нравится) collection, and defines the ordering as newest likes to oldest. This is clear enough to distinguish it from like_tracks/unlike_tracks and get_listening_history, though it never names a sibling to differentiate explicitly.

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?

It gives one implied usage scenario – use a large limit (up to 500) for taste analysis – which hints at the tool's analytical purpose. But it offers no explicit when-to-use/when-not guidance and never points to an alternative tool (e.g. get_listening_history or search) for adjacent needs.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the genuinely useful disclosure that results are grouped by day, which the agent could not infer from annotations, but says nothing about pagination, time window, or how 'limit' interacts with the day grouping.

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?

A single short sentence with no filler, and the grouping behavior is front-loaded alongside the resource. It is efficient, though it omits the detail that would have made it complete.

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?

With an output schema present, return values need not be explained, and the annotations cover the read-only nature. However, the limit parameter is undocumented and the time window of 'recently' is undefined, so an agent cannot call it fully informed.

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 0%, so the single 'limit' parameter (default 50) is undocumented everywhere. The description never mentions it, leaving the agent to guess whether it caps tracks, days, or groups.

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 names a specific resource ('прослушанные треки' / listening history) and adds a scope detail ('сгруппированные по дням'), which lets an agent separate it from get_liked_tracks or get_chart. It stops short of explicitly naming siblings or contrasting behaviors, so it stays at 4.

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?

There is no statement of when to use this tool versus alternatives like get_liked_tracks, get_my_wave, or get_chart, and no prerequisites or exclusions. Usage must be inferred entirely from the resource name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-data behavior are covered. The description adds a useful behavioral detail — that each batch is roughly 5 tracks — but says nothing about freshness, deduplication, or whether repeated calls return the same recommendations.

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?

Two compact sentences with the core purpose front-loaded and the parameter explained second. No filler; every clause earns its place.

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?

With an output schema present, return values need not be described, and the single parameter is explained. The main gap is the absence of any routing guidance against sibling recommendation tools, but otherwise the definition is adequate for this simple one-parameter read.

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 coverage is 0%, so the description carries the burden, and it does explain 'batches' as the number of portions and clarifies the ≈5-track size per portion, which is exactly the kind of meaning the bare integer schema lacks. It stops short of stating bounds or the default.

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 names a specific resource ('Моя волна' — personal recommendations) and states it returns a portion of tracks, which an agent can distinguish from search, get_liked_tracks, or get_similar_tracks. The verb is implicit ('Порция треков') rather than explicit, and it doesn't name a sibling to contrast with, so it falls short of 5.

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?

There is no guidance on when to use this over alternatives like get_similar_tracks or get_chart, nor any stated prerequisite such as authentication being required for personalized data. Usage is only loosely implied by 'персональных рекомендаций'.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond them: it operates on others' public playlists and accepts any Yandex Music domain (.ru/.com/.by/.kz), which tells the agent about reach and input flexibility.

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 front-loaded sentences: purpose first, then supported URL formats, then domain coverage. No filler, though the URL enumeration is dense and could be slightly tightened.

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?

An output schema exists so return values need no explanation, and readOnly/openWorld annotations cover safety. The description is nearly complete for a two-parameter read tool, with the only gap being the undocumented limit 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 coverage is 0%, so the description must carry the load. It compensates well for the url parameter by enumerating the accepted link shapes (user/playlist number, new uuid/lk format, /album/<id>), but it says nothing about the limit parameter (default 300), leaving half the parameters undocumented.

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?

States a specific verb (fetch tracks) and resource (by Yandex Music URL), and scopes it clearly: it works for other people's public playlists and accepts album links. The URL-based framing implicitly separates it from ID-based siblings like get_playlist_tracks, but it never names an alternative explicitly.

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?

Usage is implied rather than stated: an agent infers 'use this when you have a link.' There is no explicit when/when-not, no comparison to get_playlist_tracks or get_album_tracks, and no note on prerequisites, so the routing guidance is only suggestive.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and open-world profile is covered by structured data. The description adds one useful behavioral fact — that owner_uid reaches other users' PUBLIC playlists — but says nothing about pagination, result size, or what happens when a playlist is private or inaccessible.

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?

Two short clauses, front-loaded with the resource and then the owner_uid scoping rule. No filler sentences; every word earns its place.

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?

An output schema exists so return values need no explanation, but for a tool with a mandatory 'kind' parameter the description is incomplete: an agent cannot determine what value 'kind' expects or what it selects. The owner_uid note is good, but the central required input is left a mystery.

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 0% across three parameters, so the description must carry the load. It explains owner_uid's semantics well, but the REQUIRED parameter 'kind' is completely undefined in both schema and description, and 'limit' (default 200) is never mentioned. This leaves the primary parameter opaque.

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+resource (retrieving playlist tracks) and its default scope is clear, distinguishing it from siblings like get_liked_tracks or list_my_playlists. However, it never explains the required 'kind' discriminator, which is the core selector for WHICH playlist is fetched, so the purpose is only partially pinned down.

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?

'По умолчанию — мой плейлист; owner_uid — для чужого публичного' gives a usable rule for when to pass owner_uid versus omit it. But there is no guidance on when to use this tool over get_liked_tracks, list_my_playlists, or get_album_tracks, and no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds no behavioral context beyond annotations—it does not describe result freshness, personalization, rate limits, or other operational traits.

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, front-loaded sentence with zero waste. It efficiently conveys the tool's purpose and the parameter format.

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 read-only tool with one parameter, an output schema, and annotations covering safety, the description is largely complete. It states purpose and input format, though it could benefit from brief usage context.

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 0%, so the description must compensate. It provides concrete format examples for track_id ('123' or '123:456'), which are essential for correct invocation, though it does not explain the meaning of the colon-separated variant.

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+resource: 'Похожие треки' (similar tracks) and adds 'по версии Яндекса' to clarify the source. It is clear what the tool returns, though it does not explicitly differentiate itself from siblings like search or get_artist_tracks.

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 offers no guidance on when to use this tool versus alternatives such as search or get_artist_tracks. It simply states what the tool returns, leaving the agent to infer appropriate usage.

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

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

Annotations already declare this is a mutation (readOnlyHint=false) that is non-destructive and open-world. The description adds nothing beyond that — no mention of whether the call is idempotent, whether IDs that are already liked cause errors, batch-size limits, or rate limiting. With annotations covering the safety profile, the description still has an empty behavioral slot it could have filled.

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?

A single short sentence with no filler and the action front-loaded. It is efficient, though its brevity is partly under-specification rather than disciplined conciseness.

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?

An output schema exists, so return values need not be explained, but for a batch mutation tool with a fully undocumented parameter and zero usage context, the definition is too thin. An agent cannot determine batching behavior, error semantics, or how it pairs with unlike_tracks.

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 0% and the single parameter track_ids is completely undocumented. The plural 'трекам' weakly implies multiple IDs are accepted, but the description gives no format, count limits, or behavior for invalid/already-liked IDs, so it does not compensate for the coverage gap.

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 ('likes tracks'), which is unambiguous on its own. However, it makes no attempt to differentiate itself from the sibling unlike_tracks or explain its relationship to get_liked_tracks, so it stops short of a 5.

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?

There is no guidance on when to use this tool versus unlike_tracks, no note about prerequisites (e.g. being authenticated), and no mention of how it relates to get_liked_tracks. The agent must infer everything 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.

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

The readOnlyHint/openWorldHint annotations already establish that this is a safe, non-mutating read, so the bar is lower. The description adds one genuinely useful cross-tool fact (the 'kind' value is the playlist identifier consumed by other tools), but says nothing about ordering, result limits, or whether private/collaborative playlists are included.

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?

A single short sentence, front-loaded with the core capability and followed by a compact parenthetical. No filler; every clause earns its place.

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?

With zero parameters, an output schema present, and annotations covering the safety profile, the description needs little more. It is adequate for this simple listing tool, though a note on scope (own playlists only, ordering) would close the remaining gap.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The parenthetical about 'kind' describes an output field rather than an input, which is helpful but belongs more to return-value context.

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?

States a specific verb+resource: retrieves all of the caller's playlists. It is clearly distinguishable from track-fetching siblings like get_playlist_tracks or create_playlist, but it never names or contrasts with an alternative, so the differentiation is implicit rather than stated.

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?

Usage is only implied: you list playlists to obtain them. The parenthetical hint that 'kind' serves as the playlist identifier for other tools faintly suggests a chaining workflow, but there is no explicit when-to-use or when-not-to-use guidance, nor any named alternative.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond the annotations: no mention of irreversibility, permission requirements, or the 'my playlist' ownership constraint stated as a real limitation.

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?

A single short sentence with no waste and the action front-loaded. But it is under-specified rather than genuinely concise, since brevity comes at the cost of any useful detail.

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?

A destructive mutation tool with an output schema (no return-value explanation needed) but zero parameter documentation and no usage context. An agent cannot determine what 'kind' means or when this tool should be preferred, so the definition is incomplete for correct invocation.

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 0% and neither parameter is explained. 'Kind' (an integer) is completely opaque, and 'track_ids' is only vaguely implied by 'указанные треки'. The description fails to compensate for the coverage gap.

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?

States a specific verb and resource ('Удаляет указанные треки из моего плейлиста' = removes specified tracks from my playlist), which is clearly distinct from the sibling add_tracks_to_playlist. However, it does not explicitly reference siblings or delimit itself beyond the verb.

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 guidance on when to use this versus alternatives such as add_tracks_to_playlist, nor any prerequisites (e.g., ownership of the playlist). The description only restates the operation.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds a useful behavioral nuance not in the schema — that 'limit' controls results per category rather than a total — but says nothing about result shape, pagination, or the read-only scope beyond what annotations provide.

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?

Two compact sentences with the purpose front-loaded and no filler; each clause maps to a real function or parameter. Slightly terse given the missing query semantics, but sized appropriately.

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?

The tool is simple and read-only, the output schema exists so return values need not be explained, and the description covers the two optional parameters. The main gap is the undefined required 'query' parameter, but overall the description is adequate for correct invocation.

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 coverage is 0%, so the description carries the full burden and it only partially compensates: it explains that 'type' narrows the search and that 'limit' is per-category (a genuinely useful detail not derivable from the schema). The required 'query' parameter is left entirely undefined, and the enum values for 'type' are only in the schema.

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?

States a specific verb and resource ('Поиск по каталогу Яндекс Музыки' / search the Yandex Music catalog), which is clear and immediately distinguishable from the specific retrieval siblings like get_chart or get_liked_tracks since it is the only general search tool. It does not, however, explicitly name or contrast itself with any sibling.

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?

There is no guidance on when to use this tool versus the many specialized siblings (get_chart, get_similar_tracks, get_liked_tracks, etc.). The sentence 'type сужает поиск' describes a parameter effect, not a usage condition or alternative, leaving the agent to infer when a general catalog search is appropriate.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation semantics are covered structurally. The description adds nothing beyond restating the effect: no note on reversibility, idempotency, or whether removed tracks must currently be liked.

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?

A single front-loaded sentence with no filler. It is efficient, though its brevity borders on under-specification for a destructive operation.

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?

An output schema exists so return values need no explanation, but for a destructive write tool with zero annotation-independent behavioral detail and an undocumented required parameter, the description leaves significant gaps an agent needs to call it correctly.

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 0% for the single required track_ids parameter, and the description never mentions it. No detail is given on accepted ID format, array size limits, or whether invalid/absent IDs cause failure.

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?

States a specific verb and resource ('Убирает треки из «Мне нравится»'), making the operation unmistakable and distinguishable from like_tracks. It lacks any explicit differentiation from siblings beyond the obvious name-level distinction.

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 guidance on when to use this versus alternatives such as remove_tracks_from_playlist, nor any prerequisites or exclusions. The agent must infer the context entirely from the name.

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