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

With no annotations, the description carries the behavioral burden. 'Browse' implies a read-only, non-destructive operation, but the description does not disclose potential edge cases such as offline users, pagination, or failure behavior. It adds minimal behavioral context beyond the verb.

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 concise sentence with no redundant words. It is front-loaded with the action and object.

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 single-parameter tool with an output schema, the description captures the core functionality. It lacks caveats around user availability or result size, but the output schema handles return values. Good enough for most selection and invocation cases.

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 clarify parameters. It ties the username to 'a Soulseek user', indicating the parameter identifies whose shares to browse, but it does not add format, constraints, or how to obtain the username. The simple parameter is self-explanatory enough.

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 ('Browse') and a clear resource ('everything a Soulseek user is sharing'), making the tool's purpose evident. It does not explicitly name sibling alternatives, but the contrast with search/search_results is implicit.

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

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

The description implies the tool is used when you want a full listing of a particular user's shared files, but it offers no explicit guidance on when to choose it over search or search_results, nor any exclusions.

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?

No annotations are provided, so the description carries the behavioral transparency burden. It adds useful context by noting the operation is always available and 'only ever reduces activity,' but it does not disclose side effects like what happens to partial files or whether cancellation is reversible. The optional 'remove' parameter suggests there may be file-removal behavior that is not explained.

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 two short sentences with no filler. The primary purpose is front-loaded, and the additional availability note is compact and relevant.

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?

While an output schema exists and return values may be covered there, the description omits parameter semantics and provides no guidance on the effect of the 'remove' option. The tool is simple, but the missing parameter context and lack of alternative guidance leave the description incomplete for fully 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 the description does not mention any of the three parameters: username, id, or remove. The schema only provides names, types, and a default, so the description adds no meaning to the parameters. This is a significant gap for an agent deciding how 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 states a specific action ('Cancel') on a specific resource ('a download in progress'), and this clearly distinguishes it from sibling tools like download_status or downloads. The intent is immediately obvious 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?

The description gives concrete guidance on when the tool is usable: it is 'Always available, even when downloads are disabled.' It does not explicitly list when-not-to-use scenarios or alternatives, but the availability clarification is genuinely useful context.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It communicates that the action is asynchronous ('Queue'), that a server-side prerequisite must be met, and that inputs must exactly match prior search results. However, it does not explain permission requirements, side effects, or what the queued download entails beyond being queued.

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 two sentences with no filler. The main action comes first, followed by the prerequisite and the critical parameter guidance. Every sentence contributes meaningful 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?

The description covers the core action, prerequisite, and a key parameter constraint, and an output schema exists so return-value documentation is less critical. Still, with no annotations and four parameters, the description leaves username semantics and the optional search_id role unexplained, so it is not fully complete.

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 does add meaning for filename and size by requiring exact values from search_results, but it leaves username and search_id unexplained. Username is required and important, so the parameter guidance is incomplete.

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: 'Queue a file for download.' This is clear and distinct from the immediate action implied by the tool name. It does not explicitly contrast with sibling tools like download_status or cancel_download, but the queueing focus is enough to identify the core purpose.

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 provides a clear precondition: 'Requires the server to have been started with downloads enabled.' It also tells the agent to 'Use the exact filename and size from search_results,' which implies the recommended workflow and parameter sourcing. It does not mention alternatives or exclusions, but the context is clear.

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?

With no annotations, the description carries the behavioral burden. 'Show' suggests a read-only listing operation, but the description does not explicitly state side effects, whether progress is fetched fresh, or whether it only reflects in-memory state. It is not misleading, but it is thin.

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 six-word sentence, front-loaded with the verb and resource, contains no filler. Every word contributes.

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 zero-parameter read-only list tool with an output schema, this is largely complete. The only gap is the unresolved relationship to download_status, which could cause an agent to pick the wrong sibling.

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 input schema is empty and there are zero parameters, so there is no parameter meaning to add. The baseline of 4 applies because parameter semantics is a non-issue.

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 ('Show') and resource ('current downloads') and adds the key detail of progress. It is clear, though it does not explicitly differentiate itself from the similarly named sibling download_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?

There is no guidance on when to use this tool over download_status, download, or cancel_download. The phrase 'current downloads' implies a listing use case, but no alternatives 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?

No annotations are present, so the description carries the behavioral burden. 'Check' clearly implies a read-only status operation, and the description discloses what the call reports (state, percent, queue position). It does not detail failure behavior, but the read-only nature is strongly implied.

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, no filler. The primary purpose is stated first, followed by the parameter source requirement. 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?

The tool is simple, an output schema exists, and the description provides the crucial prerequisite. It could be slightly more explicit about not listing all downloads, but nothing essential is missing for correct invocation.

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

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

Schema coverage is 0%, so the description must add meaning. It clarifies that `id` is the transfer id and that both `username` and `id` come from `download` or `downloads`, which gives an agent the necessary provenance for both 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 uses a specific verb ('Check'), a specific resource ('one download'), and names the exact returned data: state, percent complete, and queue position. This clearly distinguishes it from the sibling tools like `downloads` and `cancel_download`.

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 gives explicit context for when to use the tool: after obtaining a username and transfer id from `download` or `downloads`. It does not explicitly state when not to use it, but the prerequisite guidance makes the intended usage clear.

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?

With no annotations, the description carries the burden, and it discloses the key behavioral trait: results arrive asynchronously, not in the immediate response. It also states the return shape (a search id). It does not mention error conditions, but those are less critical for a simple one-parameter search trigger.

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, action first, no filler. Every clause contributes: the operation, the return value, and the follow-up call.

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 one-parameter async search trigger it is complete: it states what to pass (query, via the schema), what comes back (search id), and what to do next (search_results). It lacks deeper operational context like persistence or failure behavior, but the output schema and sibling names cover the rest.

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 only a required `query` string, and the description does not document query syntax or formatting, so schema coverage is 0% and the description adds little beyond the parameter name. The phrase 'Search the Soulseek network' implies the query is the search term, which provides minimal compensation.

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 opens with a specific verb and resource: 'Search the Soulseek network.' It also distinguishes the tool from its sibling search_results by stating this call only returns a search id and results arrive later, making the role of each clear.

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

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

It provides explicit workflow guidance: run this tool, get an id, then 'call search_results a few seconds later.' It does not spell out when to prefer search_label or when not to search, so it stops 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. 'List recent searches and their state' implies a read-only operation, which is a useful signal, but it does not clarify ordering, recency limits, whether the list is empty-safe, or how 'state' is represented.

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, focused phrase with no filler. It communicates the essential action and scope efficiently, which is ideal for a zero-parameter list tool.

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

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

For a zero-parameter list operation with an output schema present, the description is largely complete. It could slightly improve by noting what 'state' means or how 'recent' is determined, but these are minor gaps rather than blockers.

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 has zero parameters, so there are no parameter semantics for the description to clarify. The baseline of 4 applies, and the description is not lacking in this dimension.

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 uses a specific verb ('List') and identifies the resource ('recent searches') and the included attribute ('their state'). It is clear and understandable, though it does not explicitly differentiate itself from sibling tools like 'search' or 'search_results'.

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 provides no guidance on when to use this tool versus alternatives such as 'search', 'search_results', or 'search_label'. There is no mention of intended context, prerequisites, or exclusions.

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?

With no annotations, the description carries the transparency burden. It discloses that the tool runs a search, waits for responses, post-filters by a bracketed label tag, and excludes coincidental matches. This gives useful behavioral context the schema cannot 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?

Three sentences with no waste. The purpose is front-loaded, and each subsequent sentence adds a distinct behavioral fact about the filtering process. Every sentence 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?

The description covers the main behavior and label parameter well, but leaves the 'formats' parameter unexplained and does not explicitly compare against sibling search tools. Given the output schema exists and the tool is simple, it is 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 description coverage is 0%, so the description must compensate. It explains the 'label' parameter via example, but it never mentions the 'formats' parameter, its default, or its effect. Param semantics are only half-covered.

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 ('Find releases on a specific record label') and clearly distinguishes the tool from plain search by explaining the bracketed-tag filtering behavior. It also implies the distinction from sibling search tools.

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 clearly conveys when to use this tool: when label-specific results are needed and coincidental word matches should be filtered out. It contrasts with 'plain search' but does not explicitly name sibling alternatives or state when-not to use it.

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

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

No annotations are provided, so the description carries the full burden. It discloses the primary behavior: retrieving peers and their files with size and bitrate, and hints that exact filename/size are needed for downloading. It does not explicitly state whether this operation is read-only, whether it can fail for expired search ids, or any pagination or filtering behavior related to the formats parameter.

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 two sentences with no filler. The main purpose is front-loaded, and the second sentence adds actionable detail about downstream usage. 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?

An output schema exists, so return-value details may be covered there, but the description still leaves meaningful gaps: no guidance on the optional formats parameter, no differentiation from sibling search-related tools, and no stated behavior for invalid or missing search ids. For a 2-parameter tool with no annotations, this is incomplete.

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 adds meaning for the id parameter by calling it a 'search id,' and it implies the result contains filename and size values used for downloading. However, the formats parameter is completely undocumented, leaving the agent to guess whether it filters formats, defaults, or modifies output.

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 a specific verb and resource: 'Get results for a search id' and says it 'Lists peers and their files with size and bitrate.' It is not a tautology and conveys the core output. However, it does not explicitly contrast itself with sibling tools like search, searches, browse, or download, so some differentiation is left to the 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?

There is no explicit guidance about when to use this tool versus alternatives such as search, browse, or downloads. The phrase 'for a search id' implies a precondition, but it does not say 'after running search, use this to retrieve results' or 'when browsing peers/files, use browse instead.' The final sentence about downloading gives downstream advice but no selection criteria.

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?

With no annotations provided, the description carries the transparency burden. It usefully discloses that wishlist entries are re-run on a schedule and only new results are reported, which is key behavioral context an agent would not infer from the tool name or schema alone.

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

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

The description is two sentences, with the action front-loaded and the behavioral consequence stated immediately after. Every sentence adds useful information and there is no verbose or redundant phrasing.

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 description explains the tool's core behavior well, but it omits guidance on the optional parameters and does not clarify when to prefer this over one-time search or other wishlist operations. While the output schema exists and covers return values, the missing parameter semantics leaves the description incomplete for an agent needing to construct a fully informed call.

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 for the three parameters. It indirectly clarifies that 'query' is the search term for the standing search, but it gives no explanation of 'formats' or 'label_filter', leaving their semantics mostly to inference from the parameter names.

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 the verb ('Add') and the resource ('a standing search to the wishlist'), which is specific and distinct from the sibling tools like wishlist_list, wishlist_remove, and wishlist_check. The term 'standing search' also signals this is not a one-time search, further differentiating it from search-related siblings.

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

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

The description makes the usage context clear: this is for ongoing monitoring where you want to be alerted about new results over time. It does not explicitly name alternatives or state when not to use it, but the recurring-monitoring framing provides adequate guidance for most agent decisions.

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?

With no annotations, the description carries the full behavioral burden. It does well by disclosing the asynchronous Soulseek arrival, the ~20s per-entry latency, and the 'only results not seen before' filtering behavior. It does not mention side effects or whether the operation is read-only, but the search-oriented wording and clear timing provide strong transparency for a zero-parameter 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 sentences, no waste. The core action is front-loaded, and the critical latency caveat follows immediately. 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?

For a zero-parameter tool with an output schema present, the description is complete. It covers what happens, the filtering rule, and the time cost. Nothing an agent needs to invoke it successfully 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?

There are zero parameters and schema coverage is 100%, so the schema has nothing left to document. The description correctly focuses on behavior rather than parameters. Baseline of 4 applies because with no parameters the description need not add parameter detail.

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 ('run'), a concrete resource ('all wishlist searches'), and a distinct scope ('report only results not seen before'). This clearly differentiates it from sibling tools like search/search_results (single searches) and wishlist_add/list/remove (list management). An agent can tell exactly what this tool does without inspecting schemas.

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

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

The phrase 'Run all wishlist searches now' conveys when to use this tool: when a batch execution of all saved wishlist searches is needed. It also distinguishes from single-search siblings by the word 'all'. However, it does not explicitly name alternatives or state when not to use it, 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?

No annotations exist, so the description must stand alone. 'List' implies a non-mutating read, but the description does not disclose output format, pagination, or any edge cases beyond the bare action.

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 four words and immediately states the action and subject. There is no filler or redundancy, making it an efficient definition for a simple list tool.

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

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

The tool has an output schema and no parameters, so minimal description is required. It is mostly complete for a simple list operation, but could benefit from noting its relationship to 'searches' or 'wishlist_check' to prevent ambiguity.

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 are zero parameters, so the empty schema is fully covered and there is nothing additional for the description to explain. Baseline of 4 applies.

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?

Description uses specific verb 'List' and resource 'standing wishlist searches', clearly identifying it as a read-only operation. It differentiates from mutating siblings like wishlist_add and wishlist_remove, though it does not explicitly distinguish from similar 'searches' 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?

No guidance is given on when to use this tool versus the sibling tools. It does not mention alternatives, prerequisites, or scenarios, leaving the agent to infer usage from the name alone.

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?

No annotations are present, so the description carries the full behavioral burden. It discloses that the operation mutates the wishlist and that indices are 1-based relative to wishlist_list, but it does not mention what happens to remaining entries after removal or invalid-index behavior. 'Remove' conveys destructiveness but not complete side effects.

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

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

The description is a single sentence that front-loads the action and packs the essential scoping detail. Every word earns its place with no filler or repetition.

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 one-parameter tool with an output schema, the description is sufficient. It states what is removed, how the target is identified, and where the index comes from. No critical calling information 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?

Schema coverage is 0% and the schema only states that 'index' is an integer. The description adds the critical semantics: the index is 1-based and refers to positions from wishlist_list. It does not specify bounds or error behavior, but the core meaning is well covered.

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 uses the specific verb 'Remove' and names the exact resource ('wishlist entry') plus the selection mechanism ('1-based index from wishlist_list'). This clearly distinguishes it from siblings like wishlist_add and wishlist_check.

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 explicitly ties the index to wishlist_list, signaling that the agent should obtain the index from that command first. It does not spell out exclusions or when not to use it, but the context is clear enough for a single-purpose removal tool.

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