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

No annotations, so the description carries the full burden. It usefully discloses the input format (http(s) .srt link), the episode-vs-title scoping effect, and the LAN reachability constraint on where the subtitle appears. It omits persistence, failure behavior, and whether the addon must be installed/configured, leaving real behavioral gaps.

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?

Four short sentences, front-loaded with the core action and effect; every sentence adds information. Slightly loose line-break formatting 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?

An output schema exists so return values needn't be described, and the mechanism/effect are covered. However, with 6 parameters at 0% schema coverage and no annotations, the definition leaves several params and failure/persistence behavior undocumented, so an agent cannot fully call it with confidence.

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 compensate for all 6 params. It explains subtitle_url format and the season/episode semantics well, but says nothing about imdb_id, label, or language (whose non-obvious default 'heb' goes unexplained). Partial compensation only.

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 (serve/add) and resource (subtitle file for a title) and explains the delivery mechanism (MCP subtitle addon, Stremio picker). It is clearly distinct from list_subtitles/remove_subtitle, though it never explicitly distinguishes itself from the near-neighbor push_subtitle.

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 one conditional: use season/episode to target a single episode, omit them for whole-title coverage. It does not say when to prefer this over push_subtitle, auto_fetch_subtitle, or sync_addon, so the alternative selection is left to inference.

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 carries the full burden, but it is a 0-parameter read operation, which caps the risk. 'List' implies a non-mutating read and an output schema exists so return values need not be described, yet the description says nothing explicit about side effects or freshness of the listing.

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 (verb, resource, scope) does work.

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 tool with an output schema and no annotations, the description covers the essential purpose. It stops short of stating what 'served' means (e.g. cached vs. available) or whether the list can be empty, but nothing required to invoke it correctly 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?

The tool takes no parameters, so there is nothing for the description to clarify. Schema coverage is 100% by default and the baseline for a zero-parameter tool 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?

States a specific verb (List) and resource (subtitles) with a clear scope modifier: 'currently served by the MCP subtitle addon.' This is distinguishable from the mutation siblings add_subtitle, remove_subtitle and push_subtitle, though the description never names or contrasts them 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?

There is no when-to-use or when-not-to-use guidance. The agent must infer the use case from the word 'List' alone; nothing says whether this is an audit of currently active subtitles versus something like stremio_auto_fetch_subtitle or sync_addon.

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 full behavioral burden and does partially deliver: it discloses the two-step interaction (opens the detail page, then presses OK to start the highlighted stream), which is genuinely useful. It omits auth/pairing requirements, failure modes, and whether it blocks, leaving meaningful gaps for a mutation-style 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?

Three short, front-loaded sentences with no padding; the core action leads and examples follow. Minor grammatical awkwardness ('presses OK') but structurally efficient.

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. For a state-changing playback tool with zero annotations, the description covers the basic workflow but omits prerequisites (pairing/login), reliability concerns (what happens if the detail page or stream fails), and the undocumented content_type 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 compensate. It documents imdb_id format ('tt1375666') and the season/episode-for-series rule, covering 3 of 4 params, but says nothing about the content_type parameter that controls movie-vs-series interpretation, leaving a real 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 (Open) and resource (a movie or series episode in Stremio) plus the target platform (Android TV), which separates it from desktop/cast siblings. However, it does not name the most likely-confusable siblings (stremio_desktop_play, stremio_cast_play) to make the distinction explicit.

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?

'For series pass season and episode' gives conditional usage for one case, implying when season/episode are needed. But there is no guidance on when to use this over the many other playback tools (desktop_play, cast_play, tv_control), and no stated 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?

With no annotations, the description carries the full behavioral burden, and it does disclose the shape of the reported state (title, state, position, duration in ms). However it says nothing about what happens when nothing is playing, what the possible 'state' values are, or whether the call is a safe read. Partial disclosure only.

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 sentence, front-loaded with the action and target, then the returned fields. Every clause carries information and nothing is padded.

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 tool with an output schema that already documents the return shape, the description covers what an agent needs to select it. The remaining gap is routing relative to the other status tools (tv_status, stremio_desktop_status), which this description leaves unaddressed.

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; the baseline for a parameterless tool applies. The description's field list describes the response, not inputs, which is harmless but not additive.

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 (Report) and resource (what Stremio is playing on the TV), and even enumerates the returned fields: title, state, position, duration. It is clearly distinguishable from generic siblings like tv_status, but it never names or contrasts with the closer alternatives (tv_status, stremio_desktop_status, stremio_cast_control).

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 at all — no statement of prerequisites, no indication of when this is preferable to tv_status or stremio_desktop_status. Usage is only inferable from the phrase 'playing on the TV'.

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 burden and does useful work: it names the write destination (Android TV Downloads folder) and discloses a non-obvious side effect of clear_player_default (forgetting Stremio's chosen video app so Android re-prompts). It does not cover overwrite behavior for an existing file, permissions/auth, or failure modes, so it falls short of exhaustive.

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-loaded with the core action in the first sentence, then a compact parameter glossary. Every line carries information, though the phrasing of the clear_player_default explanation wraps across two lines and is slightly indirect.

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, and the description covers destination, all parameters, the key side effect, and the alternative tool. It leaves open device targeting (which Android TV) and overwrite/error behavior, which are minor but real gaps for a file-push operation.

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 compensate, and it documents all three parameters: subtitle_url_or_path (URL to download from or local absolute path), filename (must end in .srt), and clear_player_default (behavioral effect). It omits the filename default value and any URL/local-path validation nuances, so it is strong but not fully complete.

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 destination scope: pushing an SRT subtitle file to the Android TV Downloads folder. It also names the sibling it is not (add_subtitle, for subtitles inside Stremio), so the agent can distinguish the two without opening either 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?

Explicitly routes the agent: 'For subtitles inside Stremio itself, use add_subtitle,' which is a clear when-not for the sibling. The clear_player_default explanation also tells the agent the scenario it enables (external player like VLC taking over), though it does not spell out broader preconditions such as requiring a paired/connected TV.

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 behavioral burden for a destructive mutation. It discloses the bulk-removal behavior via the omitted subtitle_id, but says nothing about reversibility, required permissions, or the effect on in-flight playback, which is a significant gap for a removal 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, zero filler, with the core action front-loaded and the key parameter behavior immediately after. 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?

An output schema exists, so return values need not be described. However, for a destructive tool with no annotations and 0% schema coverage, the description omits how a title/episode is targeted and what happens after removal, leaving the agent under-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% across four parameters, and the description only explains subtitle_id's omission semantics. The roles of imdb_id, season, and episode (and their defaults of 0) are left entirely undocumented, so the description 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 gives a specific verb and resource: 'Stop serving subtitles for a title,' which an agent can distinguish from add_subtitle, list_subtitles, and push_subtitle by contrast. It does not explicitly name those siblings or clarify its boundary against them, 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 conditional guidance is 'Omit subtitle_id to remove them all,' which tells the agent how to broaden the operation but not when to choose this tool over alternatives like push_subtitle or add_subtitle. Usage is implied rather than stated, and no prerequisites or exclusions 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses both the connectivity probe (failure mode) and the identity result, implying a safe read-only operation. It omits any auth prerequisites or what happens when the account is unreachable, which keeps it short of 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?

A single front-loaded sentence with no filler; the two pieces of information it returns are stated in the order an agent needs them (reachability first, identity second).

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?

No parameters and an output schema present, so the description need not explain return values. It covers both the success and failure dimension of the call, leaving only minor gaps such as auth prerequisites.

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 per the rubric the baseline is 4. There is no parameter semantics for the description to add or omit.

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?

Specific verb+resource: it reports (a) reachability of a Stremio account and (b) the signed-in identity. That is unambiguous against siblings like stremio_login, stremio_logout, and stremio_desktop_status, which cover different concerns.

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 — an agent can infer this is the pre-flight check to run before account-dependent operations, but the description never says when to call it or what condition selects it over stremio_login or stremio_desktop_status.

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 disclosure burden. It does disclose scope and that it performs reachability/latency measurement (implying outbound network calls and possible timeouts), but says nothing about read-only safety, expected duration with many addons, rate limiting, or how failures are 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?

A single front-loaded sentence with no filler. The verb and scope are stated immediately and 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 diagnostic with an output schema covering the return shape, the description supplies enough to invoke it correctly. It could be slightly stronger by noting the network-call nature and that latency results depend on live reachability.

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 are no argument semantics to document. The baseline of 4 applies; the description correctly implies the tool operates on the full installed set with no filtering input.

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 (Check) and resource (every installed addon's manifest reachability and latency). The plural 'every installed addon' implicitly distinguishes it from stremio_get_addon_manifest (single addon) and stremio_check_addon_upgrades (version currency), though no sibling is named 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 — an agent can infer this is the diagnostic tool for verifying addon connectivity. However, there is no explicit when-to-use framing, no prerequisites, and no reference to alternatives such as stremio_list_addons or stremio_get_addon_manifest.

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 usefully discloses that re-adding a removed title restores its watch state (an idempotent-restore trait), but omits auth requirements, what happens if the title is already present, and error 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?

Two front-loaded sentences with zero waste; the core action leads and the restore nuance follows as supporting 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?

An output schema exists, so return values needn't be explained, and the restore behavior is a helpful addition for a mutation tool. Only minor gaps remain: no auth note and no already-in-library behavior.

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 compensate. It clarifies the imdb_id format ('by IMDb id') and implies the content types ('movie or series'), but never maps them to the content_type parameter or notes its default, leaving that parameter effectively 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 ('Add'), resource ('movie or series to the account library'), and key ('by IMDb id'). This clearly separates it from stremio_remove_from_library and stremio_get_library. It stops just short of explicitly naming those 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?

Usage is implied by the action (adding to library), and the restore-on-re-add sentence hints at a useful edge case. However, it never states when to prefer this over stremio_mark_watched or how it relates to stremio_get_library, leaving alternatives to inference.

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 does disclose meaningful behavior: a protected-addon guard runs and an automatic backup is taken before the account write. That tells the agent the operation is destructive but recoverable and that some addons are shielded. It still omits auth/permission requirements and whether the backup can be re-applied.

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 effect, followed by the safety behavior. No filler and nothing repeated from the schema.

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

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

For a one-parameter mutation tool with no annotations, the description covers the critical unknowns: what is overwritten and that a guard plus backup precede the write. An output schema exists, so return values need no explanation; only the profile-name discovery path 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 single 'name' parameter has no schema description, so the description must compensate. 'Saved named profile' does indicate that name refers to an existing profile's name, but it does not state the accepted values or how to discover them (e.g., via stremio_list_addon_profiles), leaving a real 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 (Replace) plus the exact resource (the account addon collection) and the source of the new state (a saved named profile). This clearly separates it from stremio_save_addon_profile, stremio_list_addon_profiles, and stremio_restore_default_addons without needing to name them.

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 by 'saved named profile' – the agent infers this is the step that applies a previously saved profile. However, there is no explicit when-to-use/when-not, no mention of the prerequisite that the profile must already exist (stremio_save_addon_profile / stremio_list_addon_profiles), and no routing to the restore-default 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the desktop-running prerequisite and the hash calculation behavior, which is useful. However, it omits critical operational details: whether this is a read-only fetch or a mutating operation, what happens if no hash match is found, how result_index selects among multiple matches, error conditions, and rate limits. For a tool that auto-fetches and serves content, these gaps leave the agent with insufficient transparency.

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, front-loaded with the primary action and followed by the conditional usage instruction. It avoids verbose preamble and uses a clear imperative structure. Minor improvement possible by explicitly naming the alternative parameter path with more precision, but the size is appropriate for the task.

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 9 parameters, no annotations, and an output schema exists (so return value explanation is not needed). The description covers the two main invocation modes but leaves out key operational details: prerequisites for hashing, handling of missing or ambiguous matches, and the role of result_index. Given the parameter count and zero schema coverage, more completeness is expected, though the core workflow is communicated.

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%, meaning none of the 9 parameters have descriptions in the schema. The description explains the relationship between video_url and video_hash/video_size, and implies imdb_id is required for lookup. But it does not explain season/episode semantics, filename usage, language defaults, result_index behavior, or how video_url and video_hash interact when both are provided. With 0% coverage, the description must compensate more fully and falls short.

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 compound action: fetch a hash-matched OpenSubtitles result and serve it via add_subtitle. It names the resource (subtitle), the source (OpenSubtitles), and the mechanism (hash matching), which distinguishes it from generic subtitle tools like list_subtitles. However, it does not reference the many sibling tools (add_subtitle, push_subtitle) it interacts with, so the differentiation is implicit rather than explicit.

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 clear usage context: either pass a playable video_url while Stremio desktop is running, or provide video_hash and video_size directly. This gives the agent conditions for two distinct invocation modes. It does not state when to prefer this over manually calling add_subtitle or list_subtitles, but the complementary data requirements are well articulated.

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 burden. It signals the catalog is 'public' (no auth implied), but says nothing about pagination behavior (the skip param), result limits, or rate constraints, which matters for a paged browse operation.

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 efficient sentence with the resource and filter front-loaded. No wasted text, though it is arguably too terse for the information it omits.

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, but the tool still lacks sibling differentiation and any explanation of the three undocumented parameters. For a discoverability-focused catalog tool with three params at 0% coverage, this is insufficient.

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 only addresses genre filtering and leaves skip (paging) and content_type (movie vs series) entirely unexplained, even though content_type defaults to 'movie' and would silently constrain results.

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 (browse) and resource (public Cinemeta top catalog), which is more than a tautology. However, it does not differentiate from siblings like stremio_search_all_catalogs or stremio_search, so an agent cannot tell which catalog tool to pick 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?

No guidance on when to use this versus stremio_search or stremio_search_all_catalogs. It implies a 'top' listing but never states the conditions that select this tool or 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 full burden. It does not disclose that most actions (pause/resume/stop/seek/volume) mutate remote playback state while 'status' is a read, nor does it mention device requirements, reversibility, or failure modes.

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 tight sentence that front-loads the verb and resource with no filler. The mixed 'read or control' framing slightly blurs which actions are read-only, but the length is appropriate.

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 mutation-capable cast tool with no annotations and 0% schema coverage, the description is too thin. An output schema exists so return values need not be explained, but device identification, action-value coupling, and when to choose this over sibling control tools are all 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 description coverage is 0% and the description only loosely maps its action words to the 'action' parameter. The 'value' parameter (clearly needed for seek/volume) and the 'device' identifier format are never explained, leaving two 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 clear verb pair (read/control) and resource (cast playback) and enumerates the six actions (status, pause, resume, stop, seek, volume). However, it does not differentiate itself from siblings like stremio_cast_play, playback_status or tv_control, which plausibly overlap.

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 tool versus stremio_cast_play, playback_status or stremio_cast_devices. There is also no hint that a device must first be obtained via stremio_cast_devices, which is a likely prerequisite.

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 burden, and it discloses one important constraint: discovery happens 'through Stremio desktop', implying the desktop app must be running. It says nothing about latency, network requirements, or how failures surface, and an output schema covers the return values.

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. The verb and resource lead, and there is nothing extraneous to trim.

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 discovery tool whose output schema describes the return value, the description covers the essentials plus the desktop dependency. It could be slightly more complete by noting it is a prerequisite for the cast_play/cast_control 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; the 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?

States a specific verb (Discover) and resource (Chromecast and DLNA renderers), which cleanly separates it from the sibling cast_play and cast_control tools that act on an already-selected device. It does not explicitly name a sibling, but the discovery-vs-action distinction is inferable from the wording.

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: an agent can infer this is the prerequisite step before casting, but the description never says when to call it or that its output feeds stremio_cast_play. 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the two operating modes (direct HTTP stream vs torrent engine file) and the target device family, but says nothing about side effects such as interrupting current playback, prerequisite device discovery, or how failures are 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?

The core action is front-loaded in the first sentence and the two supporting sentences carry the input-mode rules with no filler. Slightly awkward phrasing ('local torrent engine file') but structurally tight.

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. Yet with zero annotation coverage and 0% schema coverage, the description leaves gaps: resume_position_ms is undocumented and the casting side-effects/preconditions are unaddressed, so it is only minimally sufficient for a 5-parameter action 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 compensate. It meaningfully explains device (discovered id or exact name), stream_url, and the info_hash + file_index pairing, covering most parameters, but it completely omits resume_position_ms, leaving one of five parameters unexplained 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?

The description opens with a specific verb+resource+target: 'Play an HTTP stream or local torrent engine file on Chromecast or DLNA.' Naming the device family implicitly distinguishes it from stremio_desktop_play and play, though it doesn't explicitly name those 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?

It tells the agent how to supply inputs (device accepts a discovered id or exact name; pass stream_url OR info_hash + file_index), which implies usage. However, it never states when to prefer this tool over stremio_desktop_play, play, or stremio_cast_control, nor that stremio_cast_devices should be run first to resolve a device id.

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, and it does useful work: it flags a safe default (inspect) versus a mutation that reinstalls every newer manifest 'in one guarded account collection update'. It stops short of stating auth/prerequisites or reversibility, but the safety profile is well communicated.

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, no filler, with the inspect/apply distinction front-loaded. 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 values need not be described. For a one-parameter tool the description covers the essential behavior; only minor gaps remain around what 'guarded' entails and any login prerequisites.

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 documented only as a boolean titled 'Apply' with default false. The description fully supplies the missing semantics by defining what true and false actually do.

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: comparing installed addon versions against live manifests, with an optional upgrade action. This clearly separates it from siblings like stremio_addon_health_check and stremio_install_addon, though 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?

Gives direct mode guidance: 'Leave apply false to inspect' vs 'Set apply true to reinstall...'. Clear context for choosing behavior, but no exclusions or references to related tools for when this is not the right choice.

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 burden and does well: it discloses the two-call round-trip protocol, that the first call reports page fields, and that it opens a browser configuration page (a real side effect requiring user interaction). It omits auth/permission requirements, but the interaction model is unusually well conveyed.

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 purpose, then walks the two steps in order with no filler. Three short sentences, each carrying a distinct instruction.

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 needn't be described, and the two-phase flow is fully explained. The remaining gap is the two undocumented parameters, which an agent would need to guess at, but the core protocol is 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 coverage is 0% with 4 parameters, so the description must compensate. It explains 'addon' (id, name, or transport URL) and 'configured_manifest_url', but leaves 'position' and 'open_configuration_page' entirely unexplained, so compensation is only partial.

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 ('Run a configurable addon's browser setup and install its result') and scopes it to configurable addons, implicitly distinguishing it from stremio_install_addon. It's clear what the tool accomplishes, though it never names the sibling it is not.

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 an explicit two-phase usage protocol: first call with addon id/name/transport URL, then a second call with the configured manifest URL produced. This is strong when-to-use guidance, but it does not contrast against alternatives like stremio_install_addon or stremio_sync_addon for non-configurable cases.

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 burden, and it does disclose the sort order and clarifies that position_ms is the playback stop point usable directly by a player — genuinely useful behavioral context beyond the structured fields. It falls short of stating read-only semantics, auth needs, or limits, which is why it is not 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?

Three short sentences, front-loaded with the core purpose, and every sentence earns its place by adding scope, framing, or field semantics.

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 low-complexity, single-parameter read tool with an output schema covering return values, the description is nearly complete: purpose, ordering, and field meaning are all present. Only the limit parameter and any auth/read-only expectations are left unaddressed.

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 is never mentioned in the description, so it is undocumented everywhere. The parameter is intuitive enough that this is not a severe gap, but the description does nothing to add meaning over the bare 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 ('List') and a precise resource ('part-watched titles with their resume positions'), and even scopes the ordering ('most recent first'). An agent can distinguish it from stremio_get_library or stremio_upcoming_episodes without opening any 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 line 'This is the row Stremio shows on its home board' gives useful framing for what the tool represents, and 'can be handed straight to a player' hints at the playback-resume use case. However, there is no explicit when-to-use vs alternatives, no exclusion of the library/upcoming tools, and no stated 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?

No annotations, so the description carries the full burden and largely meets it: it discloses the remote read of the downloads page, the on-disk side effect and location (Downloads folder), and the elevated-privilege caveat for installation. It omits edge behavior such as overwriting an existing file or failure modes.

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

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

Three tight sentences, front-loaded with the action and resource, then mechanics, then the one parameter override and the scope caveat. No filler and every sentence adds 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, and the description covers defaults, platform values, side effects, and the admin-password limitation. Minor gaps around overwrite behavior and any network/rate constraints keep it short of 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, and it does for target_platform by enumerating the accepted values ('Darwin', 'Windows' or 'Linux') and clarifying the default is the current machine. The destination parameter is only implied via 'saves it to the Downloads folder', so it is not fully documented.

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?

Specific verb+resource ('Download the Stremio desktop installer') with explicit mechanics (reads official downloads page, picks the .dmg/.exe/.deb matching architecture). An agent can distinguish it from siblings like stremio_desktop_launch or stremio_desktop_status purely from this text.

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: it tells the agent to pass target_platform to fetch for a different machine, and states that running the installer is left to the agent because it requires an admin password. It draws the boundary with the launch/install step but never names the sibling tool responsible for that step, leaving a small inference 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses one useful trait – that it blocks waiting for the streaming server – but omits idempotency (behavior if already running), failure modes (app not installed), and why waiting matters for downstream playback. It adds some context but leaves meaningful state-changing behavior undisclosed.

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 front-loaded, with the trigger condition following. No filler or restated name/title – every clause adds 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?

An output schema exists, so return values need not be explained, and the timing guidance is present. However, for a process-spawning tool with no annotations and 0% parameter coverage, missing idempotency and error behavior leave the definition only minimally 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% and the single parameter wait_seconds is never mentioned in the description. The phrase 'wait for its streaming server' hints at a waiting concept but does not explain that wait_seconds controls the timeout or what happens at its bound. With undocumented params, the description fails to compensate.

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?

It states a specific verb and resource ('Launch Stremio desktop on this machine') plus the consequence it waits for ('wait for its streaming server'). The purpose is unambiguous, but it does not differentiate itself from near-name siblings like stremio_desktop_open or stremio_desktop_status, 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 gives concrete triggers: 'Run this before asking the desktop app to play something' and 'after installing addons so the app pulls the new collection.' That is clear when-to-use guidance. It stops short of stating when NOT to call it (e.g., if the app is already running) or naming a preferred 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?

No annotations are provided, so the description carries the full disclosure burden. It never states whether Stremio desktop must already be running, what happens if it is not (does it fail, or launch it?), or whether this is purely UI navigation with no playback side effect. For a tool whose name implies an OS-level action, these prerequisites are the key missing behavioral facts.

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 primary action front-loaded, then the two invocation modes in parallel structure. Every clause carries information; nothing is padding.

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 page enum and id formats are covered. Still missing are the undocumented content_type parameter and the unexplained dependency on the local desktop client being installed and running, which leaves the definition only partially complete for a 5-parameter 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 compensate, and it largely does: it explains imdb_id format ('tt1375666'), the season/episode pairing for series, and enumerates the valid page values ('addons', 'library', 'board', 'search', 'settings'), none of which appear in the schema. The fifth parameter, content_type, is never mentioned despite defaulting to 'movie'.

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: 'Open a title, or a named page, in Stremio desktop on this machine.' The dual mode (title via imdb_id vs. named page) is made explicit. It does not differentiate itself from close siblings like stremio_desktop_launch or stremio_desktop_play, which an agent could easily confuse it with.

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 invocation context for both branches: pass imdb_id (plus season/episode for series) or pass one of the named pages. However, it offers no when-to-use-this-versus-alternatives guidance, and the crowded sibling set (desktop_launch, desktop_play, desktop_download) makes that omission meaningful.

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, so the description carries the full burden. It usefully discloses that streams follow installed-addon order then per-addon result order, and that video_id restores saved timeOffset. However, it says nothing about auth requirements, whether the call blocks, or what wait_seconds does behaviorally.

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 with no filler; the primary purpose leads and the ordering/selection mechanics follow. Each sentence contributes useful 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 no explanation, and the ordering semantics are covered. But with 7 params at 0% schema coverage and no annotations, the description should explain content_type values, wait_seconds semantics, and playback failure behavior; it does 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 coverage is 0% across 7 parameters, so the description must compensate. It meaningfully explains stream_index (selection from the merged list) and video_id (timeOffset restoration), but leaves season, episode, content_type, imdb_id, and especially wait_seconds 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: 'Select an installed-addon stream and start it in Stremio desktop.' The 'in Stremio desktop' scoping distinguishes it from sibling playback tools like stremio_cast_play or play, though no sibling is named 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?

Provides a conditional usage hint (pass video_id for continue-watching items so timeOffset is restored) but gives no guidance on when to prefer this over the many sibling playback tools (stremio_cast_play, play, tv_control). Usage is implied rather than 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 provided, so the description carries the full behavioral burden. It usefully discloses that this is a UI-level navigation (opens a review page rather than installing), but omits prerequisites such as whether the Stremio desktop app must be running or paired, and whether any state changes occur.

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, purpose front-loaded, alternative immediately after. No filler or restatement of the tool 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?

An output schema exists so return values need no explanation, and the routing to the alternative tool is complete. However, with zero parameter documentation and no annotations, an agent still lacks the argument semantics and the desktop-app prerequisites needed to invoke this reliably.

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%, yet the description never mentions either parameter. manifest_url is the sole required argument and content_type carries a default ('movie') whose meaning and valid values are unexplained anywhere, 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?

States a specific verb and resource ('Open an addon's install page in Stremio desktop') plus the intent ('so it can be reviewed'). It is clearly separable from siblings like stremio_desktop_open, stremio_desktop_launch, and stremio_install_addon without inspecting any 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?

Explicitly names the selecting condition ('addons that need configuring by hand') and the alternative for the opposite case ('For a headless install that also reaches every other device, use stremio_install_addon instead'). This is a textbook when/when-not with named sibling.

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 behavioral burden. It usefully discloses that the result depends on the desktop app being open and that it is cross-platform, but it never states that this is a safe read-only probe, nor what happens when the app is absent, nor any latency/answer semantics beyond the streaming-server note.

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 purpose in the first sentence, then adds two supporting sentences about platform support and the streaming-server dependency. Efficient overall, though the streaming-server aside is somewhat tangential to a status check.

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 there are no parameters to cover. The description supplies platform scope and the desktop-app dependency, leaving it essentially complete for a simple zero-arg status probe, with only the safety profile left implicit.

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 the baseline is 4. The description correctly adds nothing about inputs, which is appropriate since there is nothing to document.

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 (report whether Stremio desktop is installed and running) with a clear scope that distinguishes it from siblings like stremio_desktop_launch/open (which act) and stremio_account_status (which concerns the account, not the desktop app). An agent can identify the intent 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?

Usage is only implied. The note that the streaming server 'only answers while the desktop app is open' hints at when this check matters, but the description never states when to call this versus alternatives such as stremio_desktop_launch or stremio_streaming_server_cache, 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?

With no annotations provided, the description carries the full burden and does disclose meaningful behavior: it queries addons in order, merges results, and reports failing or empty addons separately rather than dropping them. It still omits auth/permission requirements, latency, and how the per_addon cap affects results, so the behavioral profile is incomplete.

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, front-loaded with the core purpose and followed by useful clarifying context. No obvious padding, though the middle explanatory sentence is more framing than actionable 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?

An output schema exists, so return values need not be described, and the aggregation/error-handling behavior is covered. But with 5 undocumented parameters and no annotations, the definition is not complete enough to guarantee correct invocation without opening the schema.

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 5 parameters, so the description must compensate and largely does not. It only loosely implies the title/imdb_id input and says nothing about season, episode, per_addon, or content_type, leaving four parameters undocumented in both schema and prose.

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 and resource: it asks every stream addon on the account for a title and merges results, which is clear enough for an agent to understand the aggregation behavior. However, it never distinguishes itself from close siblings like stremio_get_streams or stremio_streaming_server_streams, so an agent cannot tell which stream tool to select from the text alone.

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 contextual framing ('This is what Stremio itself does when you open a title'), which implies the intended use case of fetching playable streams for a title. But it offers no explicit when-to-use versus alternatives and no exclusions relative to the multiple sibling stream/subtitle tools.

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 behavioral burden, and it discloses almost nothing beyond the bare action. It does not say whether addon_url is a full HTTP URL or an addon id, whether the call hits the network and can time out or fail on unreachable addons, or that the operation is read-only and non-mutating.

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 that front-loads the fetch action and adds the summarize behavior without padding. It is efficient, though the extreme brevity is also the source of the missing detail in other dimensions.

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, the description needn't explain the return shape, and it gestures at the summarization outcome. However, for a tool whose only parameter is completely undocumented, the description should have covered the addon_url format at minimum, leaving a real gap for a direct-invocation 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% and the single parameter addon_url has no description at all, so the description must compensate. It adds zero clarification on the expected URL/identifier format, which is the one thing an agent could easily get wrong.

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) and resource (Stremio addon's manifest) plus an outcome (summarize what it can do). An agent can tell this apart from the general stremio_list_addons or stremio_search_addons, though it never names the related stremio_addon_health_check or stremio_check_addon_upgrades siblings it could be confused with.

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 versus inspecting an addon via stremio_show_addon, stremio_addon_health_check, or stremio_list_addons, and no prerequisites. The agent must infer from the name alone that this is for interrogating a single addon's capability declaration.

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 add real value by disclosing that include_removed returns soft-deleted entries and that watch history lives there, which is non-obvious. But it says nothing about authentication requirements, whether soft-deleted items are merged into the default result, or how large the listing can get.

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-loaded with the core action in the first sentence, followed by one compact sentence per parameter. No filler, though the parameter notes are packed into a paragraph where a short list would scan faster.

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 documentation is unnecessary, and all three optional parameters are covered. What remains thin is the behavioral side: read-only nature and result size are not stated, and with no annotations there is no structured fallback for that information.

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 description fully compensates: it explains include_removed's soft-delete semantics, gives the accepted values for content_type ('movie' or 'series'), and enumerates watched ('any', 'yes', 'no') with its sentinel value. The schema has no enums at all, so these value lists are only available here.

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?

"List the account's library titles" states a specific verb and resource, and the added qualifiers (include_removed, content_type, watched) confirm it is a filtered listing. It does not, however, distinguish itself from siblings such as stremio_continue_watching or stremio_search_all_catalogs, which an agent could plausibly confuse with a library listing.

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 explains what each modifier does but never states when to pick this tool over the many adjacent ones (continue_watching, browse_catalog, search). Usage is implied by "account's library titles" rather than made explicit, and no exclusions or prerequisites 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?

No annotations are provided, so the description carries the full burden. It does disclose the return payload (metadata plus episode list for series), which is useful, but says nothing about authentication, rate limits, failure modes, or whether lookups work for non-IMDb ids.

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; the verb, key input, and notable return content all appear immediately.

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 explanation is not required, and the read-only nature is self-evident from 'Get'. However, the undocumented content_type parameter is a real gap for a tool that must serve both movies and series.

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 clarifies imdb_id as the lookup key but never mentions content_type, whose default of 'movie' matters greatly since series metadata requires switching it — the phrase 'episode list for a series' hints at series support without explaining how to enable it.

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 (Get) and resource (full metadata for a title) scoped by an identifier (IMDb id), and notes it includes a series episode list. It does not explicitly differentiate itself from siblings like stremio_search or stremio_get_streams, but the purpose 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 required imdb_id suggests it is called after a search/browse step, but the description never states when to prefer it over stremio_search, stremio_browse_catalog, or stremio_get_streams, nor any 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?

No annotations, so the description carries the burden, and it does convey that this queries exactly one addon rather than aggregating. However, it discloses nothing about auth requirements, rate limits, or failure modes when the addon lacks the content. An output schema exists, so return-format disclosure is not required.

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; the key scoping constraint ('one specific addon') is stated immediately. It is efficient, though its brevity borders on under-specification for a 5-parameter 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 output schema covers return values, but with five parameters at 0% schema coverage the description leaves key calling details unexplained (content_type values, season/episode semantics, imdb_id format). Adequate to recognize the tool, thin 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 compensate and only partially does: 'one specific addon' hints at addon_url and 'a movie or episode' maps to content_type/season/episode. It never explains the addon_url format, valid content_type values, or that season/episode default 0 means a movie.

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 (ask/get), resource (streams), and scope ('one specific addon' for 'a movie or episode'). This distinguishes it from the aggregation sibling stremio_find_streams, which searches across sources. Clear purpose without needing 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 phrase 'one specific addon' implies this is used when you already know the addon, versus stremio_find_streams for broad search, but the alternative is never named and no when-not guidance is given. Usage is inferable but not explicit.

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 burden and does well: it discloses account-level scope ('shows up on every signed-in device'), idempotent upgrade-in-place behavior on reinstall, and the ordering effect of position. It omits auth/prerequisite requirements and any failure modes, which keeps it short of 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-loaded core action, then effect, then parameter semantics — a sensible order with no filler sentences. The device enumeration is slightly verbose but serves a real scope-disclosure purpose.

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 description covers the mutation's effects, idempotency, and ordering. Minor gaps remain: how to obtain a manifest URL, and whether installation requires the account to be authenticated.

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 compensate — and it does for position ('0 is queried first; -1 appends'), which is the non-obvious parameter. manifest_url is only implied to be a manifest endpoint URL rather than an addon id or name, leaving a small format 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 first sentence gives a specific verb (install), resource (addon), and target (the Stremio account), plus the identifying mechanism (manifest URL). An agent can distinguish this from siblings like stremio_uninstall_addon, stremio_search_addons, or stremio_reorder_addons without opening any 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 implicitly routes the agent by clarifying what reinstall does and how position affects query order, but it never explicitly says when to pick this over alternatives (e.g., find a manifest URL via stremio_search_addons first, or configure with stremio_configure_addon). Usage is inferable rather than 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?

With no annotations, the description carries the full burden, but for a zero-parameter read-only listing the risk profile is inherently low. It does disclose the shape of what is returned (ordered addon ids within each profile), which is useful behavioral context, but says nothing about ordering of the profiles themselves or failure behavior when none exist.

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 clause adds information (what is listed, and what each item contains). Nothing could be removed without losing meaning.

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 the description need not explain return values in detail, and its brief note about ordered addon ids is a reasonable supplement. For a simple no-param list tool this is close to complete, with only the absence of any usage framing holding it back.

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 no parameters, so per the rubric the baseline is 4. The description appropriately spends no space on parameter semantics that do not exist.

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 (list) and resource (saved addon profiles), plus what each entry contains (ordered addon ids). It is clearly distinguishable from siblings like stremio_list_addons and stremio_save_addon_profile, though it never explicitly contrasts itself with them.

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 mention of prerequisites, and no reference to alternatives such as stremio_list_addons or stremio_apply_addon_profile. The agent must infer that this is a read-only enumeration of previously saved profiles.

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. It does add genuine behavioral context beyond the schema: the addons are account-wide ('every signed-in device sees') and order is significant because Stremio queries addons top to bottom. However, it omits auth requirements and any note that this is a safe read, leaving the operation's safety profile unstated.

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 short sentences, front-loaded with the core action. The scope sentence and the ordering note each earn their place by informing how the agent should interpret the result.

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 the description need not explain return values, and there are no parameters to document. Given the simplicity, the description is nearly complete; only the absence of any read-safety or auth context keeps it from being fully sufficient.

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 the baseline of 4 applies. The description correctly implies nothing needs to be supplied to scope the call.

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 ('List the addons installed on the Stremio account'), which is clear and distinct from write-oriented siblings like stremio_install_addon or stremio_reorder_addons. It does not explicitly distinguish itself from stremio_search_addons, but the 'installed on the account' scope does that implicitly.

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: the agent can infer it should call this to inspect currently installed addons, but there is no explicit when-to-use, when-not, or named alternative. No prerequisites or follow-up 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?

With no annotations, the description carries the full burden and largely meets it: it discloses that the auth key survives for this server's lifetime and, with remember, is cached in the user state directory for persistence across runs. It does not state failure behavior (invalid credentials, rate limits, whether the password itself is discarded), which is the main remaining gap for a login 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?

Front-loads the core action in one short sentence, then spends two more on persistence and the third-party-account restriction. Every sentence is load-bearing, though the line break placement is a bit arbitrary and the persistence detail could be 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 not be explained, and the description covers the two things an agent actually needs: credential requirements and session persistence semantics. What is missing is error/edge-case behavior and whether prior login state makes this call unnecessary.

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 compensate. Email and password are self-evident, but the description usefully explains what remember actually does — caching the key to the user state directory so later runs stay signed in — which is more than the bare boolean default the schema provides. The slight tension between 'with remember' and a default of true is not clarified.

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 (sign in) and resource (Stremio account) with the exact credential inputs. It is trivially distinguishable from the sibling stremio_logout and from stremio_account_status, which reads state rather than establishing a session.

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 an explicit when-not: accounts created through Facebook or Google cannot use this, and points to the STREMIO_AUTH_KEY alternative for those cases. It does not cross-reference the sibling stremio_logout or clarify whether login is required before other stremio_* calls, so it falls short of full when/when-not/alternatives 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?

No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses that the credential is local ('stored ... on this machine'), implying this is a local-state mutation rather than a server-side token revocation, but it does not say whether other machines/sessions are affected, whether re-login is required afterward, or that the action is irreversible without credentials.

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 the action front-loaded and zero filler. Nothing to trim and nothing buried.

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 already documenting return values, the description covers what the agent needs to select and invoke it. The only shortfall is the unstated post-condition (does the agent/user need to re-authenticate afterwards).

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 no parameter semantics to explain; per the rubric this yields a baseline of 4. The description correctly implies a no-argument operation.

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 verb ('forget') and resource ('the stored Stremio auth key'), and adds a scope qualifier ('on this machine') that distinguishes it from a server-side sign-out. It is clearly the inverse of the sibling stremio_login, though it never names that sibling 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 — the agent can infer this is the tool to call when it wants to drop stored credentials — but there is no explicit when-to-use, no prereq/state guidance, and no mention of stremio_login as the counterpart/alternative. Adequate but with clear gaps.

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 usefully discloses two behavioral traits beyond the schema: the effect applies across every signed-in device, and marking watched clears the resume position. It does not mention auth/permission requirements or confirm reversibility, keeping it short of 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?

Two tight sentences with the core action front-loaded and the side effect following. Every sentence earns its place with 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?

Return values need not be explained since an output schema exists, and purpose plus the cross-device side effect are covered. However, for a 3-parameter mutation with 0% schema coverage and no annotations, the failure to document the identifier and content_type leaves the definition 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%, so the description must compensate for three undocumented parameters. It only implicitly hints at the watched boolean ('watched or unwatched'); imdb_id (the required identifier) and content_type (defaulting to 'movie', relevant for shows) are never explained, so an agent gets little help on required input.

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 pair (watched/unwatched) and resource (library title) plus a scope (across every signed-in device), so the action is unambiguous. It does not explicitly differentiate itself from siblings such as stremio_continue_watching or stremio_add_to_library, which caps it 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?

Usage is implied by the described side effect (leaving the continue-watching row) rather than stated as when-to-use guidance. There is no explicit alternative or exclusion (e.g. when to prefer toggling watched vs removing from library). Adequate but with a clear 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?

With no annotations, the description carries the full burden. It adds some behavioral context: 'regular episode' implies specials are excluded, and 'synced library history' names a data prerequisite. However it never clarifies whether the operation is read-only or mutating, or what auth it needs, leaving the safety profile unclear.

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 tight sentence with the core action front-loaded and no filler. It is efficient, though its brevity is arguably the cause of the missing prerequisite and parameter detail elsewhere.

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 two undocumented parameters, no annotations, and 0% schema coverage, the description does too little: it never addresses imdb_id, the include_unreleased flag, or the sync prerequisite's practical meaning. The output schema covers return values, but the invocation-relevant context is largely 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 description coverage is 0% and the description mentions no parameters at all. Neither imdb_id nor the meaningful include_unreleased toggle (which changes what 'first unwatched' returns) is explained anywhere, so the agent must guess at their semantics.

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 ('Resolve') and resource ('first unwatched regular episode') plus mechanism ('using synced library history'). It is clear on its own, but does not distinguish itself from siblings like stremio_continue_watching or stremio_upcoming_episodes, which an agent could easily confuse it with.

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 'using synced library history' hints at a prerequisite (history must be synced), but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative tool. The agent is left to infer whether this or stremio_continue_watching / stremio_upcoming_episodes is the right choice.

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 behavioral burden. It usefully discloses that 'Watch state is kept', which is genuine context for a removal operation (partial rather than total destruction), but it omits auth requirements, reversibility, and side effects on other library metadata.

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 operation is stated first and the behavioral caveat second, which is the right ordering.

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. For a simple mutation tool, the description covers purpose and one behavioral trait, but with no annotations and no param docs it leaves auth/permission context and identifier format unaddressed.

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 schema documents nothing about imdb_id. The description doesn't compensate at all—no format, source, or validity info. Only the well-known nature of an 'imdb_id' keeps this from scoring lower; with a single self-evident identifier, a 3 is fair.

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 combination: 'Remove a title from the account library.' An agent immediately understands the operation. It does not explicitly differentiate from siblings like stremio_add_to_library or stremio_mark_watched, though the name itself is distinctive.

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 or when-not-to-use guidance, no alternatives named. The tool name makes the basic purpose inferable, but the description offers nothing about context for choosing it over related library/mark-watched tools.

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 burden. It usefully discloses partial-update semantics (omitted ids keep relative order behind the passed ones) and the downstream effect on stream results, but says nothing about persistence, whether the change is reversible, or permission/error behavior for what is implicitly a mutation.

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 short sentences, front-loaded with the core action, then the partial-input rule, then the motivation. Every sentence earns its place with 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?

An output schema exists, so return values need not be explained, and the single-parameter surface is well covered. The only shortfall is the absence of any persistence/reversibility note on a mutation tool with no annotations.

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 sole parameter is just 'array of strings' in the schema. The description compensates by explaining that the list is a partial ordering, that position encodes priority, and that omitted addons are preserved behind the passed ones — meaning well beyond 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+resource (set/reorder addon query order) and clarifies the direction convention (highest priority first). It is clearly distinguishable from siblings like stremio_install_addon, stremio_list_addons, and stremio_configure_addon.

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 explains the effect (moving a preferred provider to the front changes what plays) which implies when to reach for it, but it never names an alternative tool or states when not to use this versus stremio_install_addon / stremio_configure_addon / stremio_apply_addon_profile. Usage is inferable but not explicit.

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 burden and does disclose the key behavioral fork: true preserves other addons and fills only missing defaults, while false resets the account to a stock addon list (i.e. removes non-defaults). It does not mention auth requirements or whether existing default addon configs are overwritten.

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 blocks, purpose first, then the when-to-use condition and the parameter behavior. No filler sentences; every line 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?

An output schema exists so return values need not be described, and the single parameter is fully explained. The only gap is operational context such as authentication/prerequisites for modifying an account's addons.

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, and it does: it spells out the semantics of both keep_installed=true (preserve others, backfill defaults) and false (full reset to stock list). This is more than the bare boolean 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 (reinstall) and resource (Stremio's seven default addons) plus the target (the account). It is clearly distinguishable from siblings like stremio_install_addon (single addon) and stremio_list_addons, as it is a bulk restoration of defaults.

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 an explicit trigger condition: 'Use this when the addon list is empty or broken.' That is clear context for invocation, though it never names the alternative tools (e.g. install_addon for individual repairs) an agent might weigh against 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?

With no annotations, the description carries the full behavioral burden. It implies a persisted write (a saved profile), but discloses nothing about authentication, what happens on a name collision, whether an existing profile is preserved or destroyed, or how the snapshot relates to later apply/restore calls.

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, front-loaded with the verb and the resource, with no filler. It is appropriately sized for the operation, though it is terse enough that the overwrite behavior has no place to live.

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 mutation tool with no annotations and 0% parameter documentation, the description is under-specified: overwrite behavior and the profile-lifecycle relationship to stremio_apply_addon_profile / stremio_list_addon_profiles are 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 description coverage is 0%, so neither parameter is documented structurally. The description hints at the required `name` ('under a name') but says nothing at all about `overwrite` — the one parameter whose semantics (fail vs. replace an existing profile, default false) are most consequential for correct invocation.

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?

Clear verb+resource: 'Save the account's current ordered addon collection under a name' states exactly what is persisted (the ordered addon collection) and the naming requirement. It does not, however, name the sibling it pairs with (stremio_apply_addon_profile) or distinguish itself from stremio_reorder_addons / stremio_restore_default_addons, which also mutate the addon collection.

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, when-not-to-use, or alternative guidance is given. An agent must infer that this is a snapshot operation whose counterpart is stremio_apply_addon_profile, and nothing states prerequisites (e.g., whether addons must already be installed/reordered first).

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 add one useful trait beyond the schema — the data source is the public Cinemeta catalog, implying no auth and read-only — but it says nothing about result ordering, pagination, or how 'limit' behaves. It is aware of one trait while omitting the rest.

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 the verb and resource first and zero filler. Nothing redundant and nothing that could be trimmed without losing meaning.

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 a near-duplicate sibling (stremio_search_all_catalogs) that the description never distinguishes, and all three parameters are undocumented in the schema while the description only partially covers two of them. The output schema does relieve it of explaining return values, but the remaining gaps leave an agent guessing on routing and arguments.

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 compensate. 'by name' maps to query and 'movies or series' hints at content_type, but it never states the accepted content_type values (movie/series) nor what limit controls or its default. Two of three parameters get only partial coverage.

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?

Specific verb (search) plus resource (movies/series) and even the backing catalog (Cinemeta), which lets an agent distinguish this from a generic catalog browse. It stops short of naming the near-identical sibling stremio_search_all_catalogs, 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?

The phrase 'through the public Cinemeta catalog' implies the scope condition for using this over a broader catalog search, but no when-to-use, when-not-to-use, or alternative (stremio_search_all_catalogs, stremio_browse_catalog, stremio_get_meta) is named. Usage must be inferred.

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 full burden. It discloses a non-obvious behavioral constraint: addons flagged configuration_required cannot be installed directly and must be configured in a browser to obtain the real manifest URL. It says nothing about rate limits, pagination, or whether results include uninstalled vs installed 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?

Short, front-loaded, and every sentence carries distinct information: purpose, empty-query behavior, next step, and the configuration caveat. Only minor density in the final sentence keeps it from perfect.

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 description covers purpose, usage, hand-off, and the key installation caveat. The gap is the undocumented 'limit' parameter and no note on result volume or pagination.

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 fully explains 'query' (empty string lists the directory) but never mentions 'limit' or its default/cap, leaving half the parameters undocumented 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?

States a specific verb and resource: search the official Stremio addon directory for addons to install. The 'directory' framing implicitly distinguishes it from stremio_list_addons (installed addons), though no sibling is named 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?

Gives explicit when-to-use behavior (empty query lists the whole directory), states the downstream action (pass a returned transportUrl to stremio_install_addon), and warns about the configuration_required exception. That is when, how, and the caveat in three sentences.

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 does disclose one useful behavioral trait — only catalogs that declare search support are queried — but says nothing about auth requirements, result aggregation across catalogs, failure when zero catalogs qualify, 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 front-loaded sentence with zero filler; the verb and scope constraint come first. Nothing in the sentence is redundant.

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 format need not be explained. But for a 3-parameter, unannotated tool with 0% parameter coverage, the description omits usage routing, parameter meaning, and behavioral context — leaving substantial gaps an agent must 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 neither the schema nor the description explains query, per_catalog (default 10), or content_type (default ''). 'Search' makes the query parameter inferable, but the per-catalog result cap and the content_type filter — both easy to misuse — are completely 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 (search) and resource (every installed addon catalog declaring search support), with a meaningful scope qualifier that implies breadth beyond a single catalog. It is distinguishable from a single-catalog search, though it never names the sibling (stremio_search / stremio_browse_catalog) it competes with.

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 choose this over stremio_search or stremio_browse_catalog, no preconditions, and no note about what to do if no installed catalog declares search support. The agent must infer that 'all catalogs' means the broadest search option.

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 content categories returned and the word 'Show' implies a read-only operation, but it does not explicitly state that it is non-mutating, that it requires a running desktop server, or anything about cost/latency.

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 well-formed sentence that front-loads the verb and resource with no filler or 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?

An output schema exists, so the description need not explain return values, and a zero-parameter read tool has little else to document. What remains missing is a note on the read-only nature and its relationship to the purge 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 tool takes zero parameters, which is the baseline-4 case. There is nothing for the description to disambiguate beyond the empty 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 ('Show') and resource (the desktop streaming server's cache limit, usage and torrent entries), enumerating exactly what is inspected. The read-only framing implicitly contrasts with the sibling stremio_streaming_server_purge_cache, but it never names that sibling explicitly, so differentiation relies on the tool names.

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: an agent can infer this is the inspection tool to call before deciding whether to purge. However, there is no explicit when-to-use statement, no mention of the purge_cache alternative, and no stated preconditions (e.g. server running).

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 and does disclose key traits: it stops matching torrent engines before deleting, requires confirm=true as a safety gate, and exposes the destructive scope (one torrent vs the complete desktop cache). It stops short of stating irreversibility or permission requirements.

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 short sentences, front-loaded with the action, with zero filler. The mode-selection rule follows immediately, making it easy to scan.

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. For a destructive two-parameter tool with no annotations, the description covers the confirmation gate and the two purge scopes adequately, leaving only minor gaps such as reversibility.

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, and it does: confirm is explained as needing to be set true, and info_hash is defined as either a single torrent selector or empty for a full-cache purge. Both parameters gain meaning beyond the bare 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 (Delete) and resource (cached torrent data), plus the secondary action of stopping matching torrent engines. An agent can tell it is the destructive counterpart to the cache-listing sibling, though no sibling is named explicitly to sharpen the 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?

The description tells the agent how to invoke it (set confirm=true; pass one info_hash or leave empty for a full purge), which is genuine usage guidance. However, it never states when to choose this over alternatives like stremio_streaming_server_cache, so context selection is only 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?

With no annotations, the description carries the full burden. It discloses the runtime prerequisite (desktop app running) and implies a read-only inspection, which is valuable. But it does not state permission/auth needs, whether any state is affected, or how results are scoped beyond the info_hash.

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 the purpose front-loaded and the parameter guidance following. No filler; the only minor cost is the awkward line wrapping, which is cosmetic rather than substantive.

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. Combined with the stated prerequisite and parameter behavior, the definition is complete enough to call correctly, with the only gap being no explicit routing to sibling 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?

Schema coverage is 0%, so the description must compensate, and it does: it explains that info_hash selects a single engine while an empty value inspects all. This is exactly the semantics an agent needs for the one required-free parameter.

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 (List) and concrete resources (active torrent engines, transfer rates, per-file download progress). It is clearly distinguishable by content from write-oriented siblings like purge_cache, though it never names an alternative for routing.

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 a precondition (Stremio desktop app must be running) and explains the two usage modes for the parameter, which is helpful. However, it never says when to choose this over sibling diagnostics like stremio_streaming_server_cache or stremio_desktop_status, so usage is only 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?

With no annotations, the description carries full behavioral burden. It usefully discloses the side effect of opening a browser auth page and the required second invocation, but says nothing about state on repeat calls (addon already configured), what sync overwrites, permission requirements, or failure modes when the user does not authorize.

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 core action and then the critical sequencing caveat. No filler, 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?

An output schema exists, so return values need not be described. For a two-step auth-and-install flow the description covers the essential sequence, but omits idempotency/overwrite behavior that an agent would want before re-running.

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?

One parameter (open_auth) at 0% schema description coverage. The description implies the browser page opens on the first call, which loosely maps to open_auth=true, but never explains the parameter or what open_auth=false does, so it only partially compensates 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 action pair (link Trakt account, then install/refresh the Trakt addon), which clearly distinguishes it from generic addon siblings like stremio_install_addon or sync_addon. It does not explicitly name those siblings as alternatives, 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?

Gives explicit sequencing guidance: the first call opens the authorization page, and after authorizing the user must run the tool again. That is real when-to-use instruction. It lacks any when-not-to-use or alternatives for users who only want to install a non-Trakt addon.

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, and it does disclose the Android 11+ requirement, the code length, the host default, and that connect_port triggers a follow-up connection. However, it omits prerequisites (wireless debugging enabled, network reachability), failure/timeout behavior, and the fact that this establishes persistent state on the device — meaningful gaps for a pair/session-establishing 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?

Three tight sentences, front-loaded with the core action and followed by only the parameter clarifications that add value. No filler or restated schema noise.

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 the description covers all four parameters plus the conditional connect flow. It is only slightly incomplete for a stateful pairing operation because prerequisites and failure modes are 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 description coverage is 0%, so the description must compensate, and it nearly does: pairing_port is defined as the port beside the pairing code, host has a stated default (ANDROID_TV_HOST), connect_port has both meaning and conditional behavior, and pairing_code maps to the 'six-digit wireless code'. Only minor type/format detail is missing, so it falls just short of fully self-sufficient.

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 ('Pair adb with an Android 11+ TV') plus the required credential ('six-digit wireless code'), which is unambiguous. It is clearly distinguishable from sibling tools like tv_control, tv_status, and tv_screenshot, which operate on an already-paired device.

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 concrete conditional rule — pass connect_port when the TV exposes a separate wireless debugging port — which tells the agent when a non-default path applies. It lacks any explicit when-not or alternative-tool guidance (e.g., relationship to tv_control/tv_status as the follow-up step), 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 are provided, so the description carries the full behavioral burden. It discloses that the target is 'the account' and how the addon is identified, but says nothing about reversibility, whether reordering or addon profiles are affected, or any auth/permission requirement for a destructive mutation.

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 sentence, front-loaded with the action and scope, with the identifier options appended. No filler and nothing redundant.

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 single parameter's accepted forms are covered. However, for a destructive account mutation with zero annotations, the description should at least indicate irreversibility or re-authentication needs; it leaves that gap unfilled.

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 'addon' parameter, but the description compensates by stating the accepted forms: a manifest URL or an addon id. That is exactly the detail the schema omits, though it gives no example format for either form.

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 ('Remove an addon from the account') and identifies the two accepted identifiers, which cleanly distinguishes it from siblings like stremio_install_addon, stremio_list_addons and stremio_restore_default_addons. It does not name any sibling explicitly, 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?

The description gives no when-to-use or when-not-to-use guidance and never mentions alternatives (e.g., stremio_restore_default_addons when the goal is a full reset, or stremio_install_addon for the inverse operation). Usage is only inferable from the verb itself.

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 behavioral burden. It discloses the library scope but omits meaningful behavior: the actual window defaults to 90 days despite "soon," results are capped at 50, and no auth/rate-limit context is given. A mutation isn't involved, but for an unannotated tool this 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 front-loaded sentence with no filler, stating the action and the scope immediately. Nothing in the sentence is redundant or misplaced.

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 prose, but the two visible parameters are undocumented in both schema and description and there are no annotations to compensate. For a time-windowed list tool, the semantics of the window and cap are exactly what an agent needs and they 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 description coverage is 0% and neither parameter is mentioned in the description. "Releasing soon" vaguely gestures at the days window, but the agent gets no explanation of what days means, its 90-day default, or that limit caps the returned episodes.

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: "List episodes releasing soon for series in the account library." The library scoping is clear and the concept is distinct from stremio_next_unwatched_episode, but the description never names or contrasts that adjacent sibling, so differentiation is left to inference.

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 by "releasing soon for series in the account library," which tells the agent the population being searched, but there is no explicit when-to-use guidance, no stated prerequisites, and no routing away from stremio_next_unwatched_episode or stremio_continue_watching.

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 adds genuinely useful scope information ('Every other installed addon is left untouched'), implying a non-destructive, targeted mutation, but omits whether login/auth is required, what happens if the addon is already installed (idempotency), and whether the operation 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 short sentences, front-loaded with the action and followed by the trigger condition and scope guarantee. Every sentence earns its place with no filler.

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