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

Annotations declare a non-read-only, non-destructive, closed-world mutation, and the description adds the crucial behavioral nuance that approving does NOT enqueue downloads — a genuinely useful clarification of side-effect scope beyond the annotations. It still doesn't state what state the tracks move to or whether approval is reversible.

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 tight sentences, front-loaded with the action and the two modes, with the disambiguation against queue_downloads placed last where it is most needed. Dense but no filler.

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 4-parameter mutation with no output schema and no parameter descriptions in the schema, the description supplies enough to invoke correctly and to know the side-effect boundary. Missing only the interplay of the two mutually-exclusive-looking selectors and the post-approval state.

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?

With 0% schema description coverage, the description carries the full burden and does well: it defines track_ids, explains that candidate selects which pick (0 = best), and describes min_confidence as a threshold selector. playlist_id is left undocumented, and the precedence when both track_ids and min_confidence are supplied is unstated.

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 (approve) and resource (candidates/tracks in a playlist) and explicitly separates its effect from queue_downloads. An agent can distinguish this from sibling tools like queue_downloads and review_candidates without opening a 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?

Explains the two selection modes (explicit track_ids vs min_confidence threshold) and clarifies the boundary with queue_downloads ('Approving queues nothing; queue_downloads does'). It lacks an explicit statement of when approval is a prerequisite step or when to prefer review_candidates first, so it stops short of full routing 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=false, destructiveHint=false, and openWorldHint=false, so the agent knows this mutates state but is not classified as destructive. The description adds only that the target is a 'matching job,' without saying whether partial progress is preserved, whether cancellation is reversible, or what happens when no job is running.

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 arguably too terse to carry the needed behavioral 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?

For a state-mutating job-control tool with no output schema and no supporting annotations beyond the safety profile, the description omits error/edge-case behavior and job lifecycle context. An agent lacks enough to know what happens on cancellation or in the no-job-running case.

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%, but there is only one parameter named playlist_id, whose meaning is largely obvious from the name. The description does not clarify the identifier's format or relationship to the job, so it adds minimal value while the near-trivial parameter keeps this at baseline.

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 ('Stop') and resource ('the running matching job of a playlist'), which is clear enough to distinguish from read tools like status or get_music. It does not explicitly differentiate itself from a hypothetical start/resume counterpart, but the resource scope 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?

No guidance on when to use this versus siblings such as status, sync_playlist, or review_candidates. No preconditions are stated (e.g., whether a job must be running, what happens if none is).

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=false, so the safety profile is covered. The description adds valuable non-obvious context: the result is prescriptive ('says how to fix it'), telling the agent the output is actionable remediation rather than raw state.

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, extremely tight, with the nature of the check front-loaded and the usage trigger immediately after. No filler, no restatement of the name.

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 parameterless, read-only diagnostic tool with no output schema, the description covers what it probes and the shape of the answer (remediation advice). Enough to invoke correctly; only a note on expected failure output or how it relates to 'status' is missing.

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?

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly spends no words on nonexistent arguments.

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 concrete diagnostic verb (health check) with three enumerated checks: reachability of Nicotine+, existence of the music dir, and configuration state. It is specific enough to distinguish from the other wiki/queue tools, though it does not explicitly contrast with the similarly-scoped sibling 'status'.

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?

Gives a clear trigger condition: 'Call this first when something fails', which tells the agent when to select it. It stops short of naming an alternative or stating when NOT to use it (e.g., versus 'status'), so it is clear context rather than full routing 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 only say readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds substantial non-obvious behavior: it hits MusicBrainz, skips assets already in the library, launches a background job against Soulseek, queues every match at or above min_confidence, and requires no further confirmation. The 'no extra confirmation' disclosure is exactly the kind of side-effect detail an agent needs before calling.

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?

Dense but front-loaded: the item format spec and the pipeline description come before the follow-up instruction. Nothing is redundant, though the single long sentence packing MusicBrainz/Soulseek/queueing could be split for readability.

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 3-param, no-output-schema tool with a background job, the description covers the important lifecycle well, but it references status(playlist_id) while no playlist_id is defined in the input schema and no output schema exists to explain what the call returns. The meaning of lossy is also left to inference.

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 params. It precisely specifies the item string grammar ('Artist - Title' vs 'Artist - Album (album)') and explains min_confidence as the queueing threshold. The lossy parameter is never mentioned, leaving one of three 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+resource ('Fetch named songs and albums in one call') and goes further by describing the full pipeline (MusicBrainz resolution, library de-duplication, Soulseek search, queueing). This is clearly distinguishable from siblings like queue_downloads, sync_playlist, and status.

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?

Gives clear operational context: items must be supplied in a specific format, the request itself acts as consent ('no extra confirmation'), and the caller should follow up with status(playlist_id) in a minute or two. It does not explicitly name when to prefer this over siblings such as queue_downloads or sync_playlist, 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.

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

Annotations state readOnlyHint=false, destructiveHint=false, so the agent knows this is a non-destructive mutation. The description adds that yes=False gives a preview and yes=True performs the queueing, which is useful. However, it doesn't describe whether queued transfers are reversible (cancel_job suggests possible), rate limits, or what happens to already-queued items.

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?

Compact, front-loads the conditional behavior. Could be slightly clearer with structured formatting, but every sentence conveys needed 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?

For a 3-param tool with 0% schema coverage and no output schema, the description covers the two optional params but omits playlist_id semantics and the return format of the dry-run totals. It's adequate but has clear 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?

Schema coverage is 0%, so the description must carry the full burden. It explains the yes flag (boolean default false) and min_confidence (approves candidates at or above it), but says nothing about playlist_id (required integer) beyond implying a playlist exists. The meaning of min_confidence relative to 'confidence' is not fully clear.

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 clear split behavior: dry-run style total preview without 'yes', actual queueing with yes=True. This is a specific verb+resource combination, though the two-mode behavior is somewhat non-standard for a tool named 'queue_downloads'.

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?

Implies when to use the dry-run (show totals to user) vs actual execution (yes=True), but doesn't explicitly name alternatives in the sibling list (e.g., approve_tracks, review_candidates) or state exclusion conditions.

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 and openWorldHint annotations already establish the safety profile, and the description adds useful behavioral detail: it lists what the result includes (confidence, quality, scoring rationale, user queue) and explains that doubtful_only hides high-confidence items and status='not_found' surfaces missing Soulseek results. It does not contradict 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?

The description is compact and front-loads the most important content. The two sentences are dense but do not waste words, though the first sentence is more of a content summary than an action statement.

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 tool with five parameters, no schema descriptions, and no output schema, the description is incomplete. It gives some return-field context and filter behavior, but it omits key parameter explanations and workflow guidance relative to sibling tools like approve_tracks and skip_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%, so the description must carry parameter meaning. It explains doubtful_only and partially explains status, but it leaves limit, offset, playlist_id, and the default status='candidates' undocumented, despite there being five parameters.

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 conveys that this tool retrieves tracks needing a decision along with candidate metadata, but it uses a noun phrase rather than a clear verb + resource. It does not explicitly distinguish the tool from siblings such as approve_tracks or skip_tracks, leaving the exact action to be inferred.

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 explicit when-to-use guidance, no when-not-to-use guidance, and no named alternatives. The description only explains filter behavior for doubtful_only and one status value, which is parameter semantics rather than usage routing.

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 and destructiveHint=false, so the agent knows this mutates state non-destructively. The description usefully adds the consequence (exclusion from matching and M3U generation), but says nothing about persistence, undo, or whether the skip is scoped to this run or permanent.

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; every word contributes to conveying the tool's effect. Ideal size for a simple two-parameter action.

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 mutating tool with 0% schema coverage, an undocumented 'reason' parameter, and no output schema, the one-line description is too thin. It should at minimum clarify what the skip affects and what happens to the excluded 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% for two parameters, and the description only obliquely references track_ids via 'these tracks'. The 'reason' parameter (defaulting to 'skipped by user') is never mentioned, so 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?

The description states a specific action (exclude tracks) and its concrete effect (out of matching and the M3U), which is enough to tell it apart from curation siblings like approve_tracks or review_candidates. It lacks any explicit naming of alternatives, but the verb+resource+effect 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?

Usage is only implied: the phrase 'leave these tracks out of matching and the M3U' suggests a curation step, but there is no statement of when to prefer this over review_candidates/approve_tracks or what prerequisites exist. An agent can infer intent but gets no routing 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 declare readOnlyHint=false with destructiveHint=false, and the description discloses exactly why: finished downloads are filed into the library (tags normalised) as a side effect of a call that looks like a read. That is meaningful context annotations alone don't supply. It stops short of saying whether the filing is idempotent or requires any auth.

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-loading scope and key outputs before the side-effect disclosure and the 'next' field note. The opening 'All playlists, or one playlist:' is a clipped fragment that reads slightly awkwardly, but no sentence is filler.

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 no output schema, the description covers what is returned (state counts, job, progress), the mutation side effect, and the guidance field well enough for correct invocation. Only edge details like pagination or job-failure reporting are absent.

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% and the single parameter is only titled 'Playlist Id', but the description compensates by explaining that omitting it returns all playlists while supplying one scopes to that playlist. That resolves the optional-vs-required ambiguity the schema leaves open.

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 conveys a status/inspection tool via specific outputs: counts by state, running or last job, download progress, plus the 'next' guidance field. The resource and scope ('all playlists, or one playlist') are stated, though the opening fragment is ellipted and no verb like 'report' appears. It does not differentiate itself from any sibling tool by name.

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 it should call this to see counts/progress and that the 'next' field routes follow-up actions. There is no explicit when-not or named alternative (e.g. vs. get_music or review_candidates), so guidance stays at the implied level.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), it discloses that matching runs in the background, that external services (MusicBrainz, Soulseek) are contacted, and that side effects are gated behind yes=True. This is exactly the extra context annotations cannot convey.

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 dense, front-loaded sentences with no filler; the accepted-input parenthetical is long but earns its space by defining the required target parameter. The workflow instruction is placed last, which is the right order.

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 no output schema, the description correctly covers lifecycle (background job, status polling), safety gating, and next steps. The remaining gap is the semantics of lossy and min_confidence, 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 description coverage is 0%, so the description must carry parameter meaning. It covers target well (valid input forms) and mentions yes=True, but says nothing about lossy or min_confidence (default 0.85), leaving two of four parameters undocumented in either place.

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 (sync/import) and resource (playlist) and enumerates accepted target forms (Spotify export, CSV, M3U, JSPF, XSPF, share URL, existing playlist id). It also names the downstream pipeline stages (resolve on MusicBrainz, diff, match on Soulseek), which clearly separates it from status and queue_downloads.

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 states the condition for the destructive path (nothing is downloaded unless yes=True, which the user must have asked for) and the required follow-up sequence (status(playlist_id) until finished, then queue_downloads). The alternatives in the workflow are named, not implied.

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, and the description adds real value on top: it specifies what actually gets removed (lossy duplicates of FLACs), that the default path is a non-mutating dry run producing a report, and that mutation requires explicit user consent. It stops short of saying whether changes are reversible or how the report is surfaced.

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 with no filler; the operation scope is front-loaded ahead of the safety-critical apply semantics. The second sentence is dense but each clause about apply carries operational weight.

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 no output schema and no parameter descriptions, the description carries the full burden, and it covers the destructive path, the dry-run default, and the consent requirement well. It is incomplete on 'force', on whether a dry-run report is returned or written to a file, and on whether the file renaming/tag normalisation is undoable.

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 both parameters. The description fully explains 'apply' (dry run vs. mutation), but 'force' is never mentioned anywhere, leaving half the parameters undocumented in both the schema and the prose. That is a meaningful gap for a destructive tool.

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 verb+resource ('Library clean-up') and enumerates the concrete sub-operations (normalise tags, drop lossy duplicates of FLACs, file as Artist/Album/NN - Title), which is far more than a restated name. It does not, however, explicitly distinguish itself from plausible siblings such as 'doctor' or 'review_candidates', so an agent must infer the boundary.

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 clearly states the when-to-use split for the main switch: apply=False is a dry run that writes a report, apply=True changes files. It also imposes a procedural precondition (only after the user's yes to the listed deletions). What's missing is guidance on alternatives — e.g., when to run 'doctor' or 'review_candidates' instead of tidying.

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 and openWorldHint=true, but the description adds substantial value beyond them: the CC BY-SA attribution obligation, the fact-only constraint for manual writes, and the iterative to_write/remaining loop contract. It still does not state auth requirements or rate limits, keeping it below a 5.

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?

Front-loads the core action in the first clause and keeps to three dense sentences with no filler. The heavy use of backticked identifiers makes it information-rich but slightly harder to scan than a cleaner breakdown would be.

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 no output schema, the description correctly explains the return shape (to_write, remaining) and the follow-up workflow. Combined with the annotation safety profile, an agent has nearly everything needed, though permission/pagination edge cases remain unstated.

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% and the single parameter has only a title and default, so the description must compensate. It does clarify that limit caps 'entries per call', but gives no range, unit nuance, or behavior when omitted beyond the default value already 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 (fill) and resource (entries without text) and the exact content used (English Wikipedia lead paragraphs linked via MusicBrainz). It also distinguishes itself from the sibling wiki_write by explaining that the leftovers go there instead, so an agent can route correctly.

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?

Gives clear operational context: 'Call again while remaining > 0' and 'store each with wiki_write' for the entries this tool cannot fill. It does not explicitly say when NOT to use it versus wiki_todo or wiki_sources, so it falls just short of full alternative routing.

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 openWorldHint=true, readOnlyHint=false, and destructiveHint=false, so the safety profile is partially covered. The description adds a useful list of returned data fields, but it does not explain why the tool is not read-only, what side effects may occur, or any network/rate-limit behavior.

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 that lists the returned data without filler. It is dense but efficient, using a parenthetical to handle the album/artist switch compactly.

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 no output schema, the description does the work of enumerating return fields and the artist/album distinction. It omits sibling-tool context and return format details, but for a two-parameter retrieval tool those gaps are minor.

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. It successfully clarifies that album=None selects artist-level facts and that providing an album switches to album-level data, which is the key semantic needed to invoke the tool correctly.

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 clearly states what the tool returns (facts and links) for either an artist or an album, distinguishing both modes via album=None. It does not, however, differentiate itself from sibling tools like wiki_todo, wiki_fill, or wiki_write, so it falls 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?

The only usage hint is the parenthetical album=None, which explains parameter behavior but not when to choose this tool over alternatives. There is no explicit context, prerequisites, or exclusion 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 only declare readOnlyHint=false, openWorldHint=false, and destructiveHint=false, so the safety profile is mostly negative and uninformative. The description usefully discloses the return contents (tracks, year, MusicBrainz ids) but says nothing about auth requirements, whether include_all alters the result set, or side effects of the write steps it recommends.

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 dense, front-loaded sentences with no filler; the resource definition comes first and the routing guidance second. The telegraphic phrasing (fragments, semicolons) is slightly terse but every clause carries 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?

With no output schema and a single boolean parameter, the description covers the return contents and the downstream workflow well, but leaves include_all unexplained and omits any note on expected volume or pagination for a todo-list style 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?

There is one parameter, include_all, with 0% schema description coverage, and the description never mentions it or explains what 'all' adds relative to the default. The name is suggestive but the description does not compensate for the missing schema documentation.

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 identifies a specific resource set ('artists and albums with no bio/wiki text') and the payload a caller gets back ('tracks, year, MusicBrainz ids'). The verb is implicit rather than stated ('lists'/'returns'), but the scope is clear enough to distinguish it from wiki_fill, wiki_sources, and wiki_write.

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 explicitly positions itself in a workflow ('Start here, then wiki_fill') and names the alternative path ('write the rest yourself with wiki_sources + wiki_write'). It stops short of a true when-not-to-use statement (e.g. how include_all changes the recommended next step), so it is strong rather than complete.

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 declare destructiveHint=false, but the description says 'force replaces existing text,' which describes a destructive overwrite. This directly contradicts the annotation, forcing a score of 1 under the contradiction rule.

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 dense paragraph that front-loads the action and destination. The attribution example earns its place, though the semicolon-heavy structure is slightly run-on.

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 6-parameter write tool with no output schema and 0% schema descriptions, the description covers most behavioral and content requirements. However, it leaves url undocumented and gives no sibling-usage routing.

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. It explains album=None, content formatting rules, attribution format, and force behavior, but it omits the url parameter entirely.

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 ('Store') and resource ('text for an artist (album=None) or an album'), with a clear sidecar/cache destination. It does not explicitly differentiate itself from sibling wiki tools such as wiki_fill or wiki_sources, so it falls 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?

Provides formatting, content, and attribution rules, but does not say when to use this tool versus alternatives like wiki_fill or wiki_sources. No prerequisites, exclusions, or routing guidance 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 declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, marking this as a local write with no external effect. The description adds a useful side effect (the missing tracks are listed), but says nothing about whether an existing file is overwritten, what permission/path constraints apply, or what happens when path is omitted.

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 compact sentence that front-loads the action and its ordering constraint, with the side effect appended. No filler, though it is arguably too short for the parameter gaps it must cover.

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 two-parameter mutation tool with no output schema and no enum/nested complexity, the description covers the action, the format, the ordering, and the return hint. It is still incomplete on parameter semantics and overwrite behavior, but the surface area is small.

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% and neither parameter is mentioned in the description: playlist_id's meaning is left to the name, and the optional path (an anyOf string/null with a null default) is completely unexplained, so the agent cannot tell whether omitted path writes alongside the playlist or to a default location.

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 (write) and resource (playlist as M3U8) plus the ordering rule and the source of truth (local files). An agent can distinguish it from siblings like sync_playlist or tidy_library, though the tool is never named against those alternatives.

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 vs when-not guidance, no mention of a prerequisite (e.g. run after sync_playlist), and no explanation of when the optional path matters. Usage must be inferred entirely from the verb.

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